Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLVM: The bad parts

npopov.com

Post reply on HN
Print view View original

31–40 of 81 posts

Re: LLVM: The bad parts

#31

Post by CalChris »

pizlonator wrote: post #7
theresistor wrote: post #5

Earlier quoted context omitted.

> It might be that regalloc needs to be taught to rematerialize It knows how to rematerialize, and has for a long time, but the backend is generally more local/has less visibility than the optimizer. This causes it to struggle to consistently undo bad decisions LICM may have made.

> It knows how to rematerialize That's very cool, I didn't realize that. > but the backend is generally more local/has less visibility than the optimizer I don't really buy that. It's operating on SSA, so it has exactly the same view as LICM in practice (to my knowledge LICM doesn't cross function boundary). LICM can't possibly know the cost of hoisting. Regalloc does have decent visibility into cost. Hence why this…

> to my knowledge LICM doesn't cross function boundary

LICM is called with runOnLoop() but is called after function inlining. Inlining enlarges functions, possibly revealing more invariants.

Re: LLVM: The bad parts

#32

Post by pizlonator »

weinzierl wrote: post #28
pizlonator wrote: post #4

This is a good write up and I agree with pretty much all of it. Two comments: - LLVM IR is actually remarkably stable these days. I was able to rebase Fil-C from llvm 17 to 20 in a single day of work. In other projects I’ve maintained a LLVM pass that worked across multiple llvm versions and it was straightforward to do. - LICM register pressure is a big issue especially when the source isn’t C or C++. I don’t think…

"LLVM IR is actually remarkably stable these days." I'm by no means an LLVM expert but my take away from when I played with it a couple of years ago was that it is more like the union of different languages. Every tool and component in the LLVM universe had its own set of rules and requirements for the LLVM IR that it understands. The IR is more like a common vocabulary than a common language. My bewilderment about L…

> like the union of different languages

No. Here are two good ways to think about it:

1. It's the C programming language represented as SSA form and with some of the UB in the C spec given a strict definition.

2. It's a low level representation. It's suitable for lowering other languages to. Theoretically, you could lower anything to it since it's Turing-complete. Practically, it's only suitable for lowering sufficiently statically-typed languages to it.

> Every tool and component in the LLVM universe had its own set of rules and requirements for the LLVM IR that it understands.

Definitely not. All of those tools have a shared understanding of what happens when LLVM executes on a particular target and data layout.

The only flexibility is that you're allowed to alter some of the semantics on a per-target and per-datalayout basis. Targets have limited power to change semantics (for example, they cannot change what "add" means). Data layout is its own IR, and that IR has its own semantics - and everything that deals with LLVM IR has to deal with the data layout "IR" and has to understand it the same way.

> My bewilderment about LLVM IR not being stable between versions had given way to understanding that this freedom was necessary.

Not parsing this statement very well, but bottom line: LLVM IR is remarkably stable because of Hyrum's law within the LLVM project's repository. There's a TON of code in LLVM that deals with LLVM IR. So, it's super hard to change even the smallest things about how LLVM IR works or what it means, because any such change would surely break at least one of the many things in the LLVM project's repo.

Re: LLVM: The bad parts

#33

Post by pizlonator »

CalChris wrote: post #31
pizlonator wrote: post #7

Earlier quoted context omitted.

> It knows how to rematerialize That's very cool, I didn't realize that. > but the backend is generally more local/has less visibility than the optimizer I don't really buy that. It's operating on SSA, so it has exactly the same view as LICM in practice (to my knowledge LICM doesn't cross function boundary). LICM can't possibly know the cost of hoisting. Regalloc does have decent visibility into cost. Hence why this…

> to my knowledge LICM doesn't cross function boundary LICM is called with runOnLoop() but is called after function inlining. Inlining enlarges functions, possibly revealing more invariants.

Sure. Any pass that is scoped to functions (or even loops, or basic blocks) will have increased scope if run after inlining, and most passes run after inlining.

In the context of this thread, your observation is not meaningful. The point is: LICM doesn't cross function boundary and neither does regalloc, so LICM has no greater scope than regalloc.

Re: LLVM: The bad parts

#34

Post by anonymous908213 »

phplovesong wrote: post #16
hu3 wrote: post #8

Earlier quoted context omitted.

Go is sometimes criticised for not using LLVM but I think they made the right choice. For starters the tooling would be much slower if it required LLVM.

Also OCaml. Having a own compiler is THE way for language development. IMHO.

Personally I think a happy medium is to compile to C99. Then, after your own compiler's high-level syntax transformation pass, you can pass it through the Tiny C Compiler which is somewhere on the order of ~10x faster than Clang -O0. When you need performance optimizations at the cost of build speed, or to support a compilation target that TCC does not, you can freely switch to compiling with Clang, getting much of the value of LLVM without ever specifically targeting it. This is what I do for my own language, and it makes my life significantly easier and is perfectly sufficient for my use, since as with most languages my language will never be used by millions of people (or perhaps only ever one person, as I have not deigned to publish it).

I think writing a compiler targeting machine code from scratch only really makes sense if you have Google's resources, as Go did. That includes both the money and the talent pool of employees that can be assigned to work on the task full-time; not everyone has Ken Thompson lying around on payroll. To do better than LLVM is a herculean feat, and most languages will never be mainstream enough to justify the undertaking; indeed I think an undertaking of that scale would prevent a language from ever getting far enough along to attract users/contributors if it doesn't already have powerful backing from day 0.

Re: LLVM: The bad parts

#35

Post by nikic »

anarazel wrote: post #30

FWIW, the article says "Frontends are somewhat insulated from this because they can use the largely stable C API." but that's not been my/our experience. There are parts of the API that are somewhat stable, but other parts (e.g. Orc) that change wildly.

Yes, the Orc C API follows different rules from the rest of the C API (https://github.com/llvm/llvm-project/blob/501416a755d1b85ca1...).

Re: LLVM: The bad parts

#37

Post by jcranmer »

pizlonator wrote: post #32
weinzierl wrote: post #28

Earlier quoted context omitted.

"LLVM IR is actually remarkably stable these days." I'm by no means an LLVM expert but my take away from when I played with it a couple of years ago was that it is more like the union of different languages. Every tool and component in the LLVM universe had its own set of rules and requirements for the LLVM IR that it understands. The IR is more like a common vocabulary than a common language. My bewilderment about L…

> like the union of different languages No. Here are two good ways to think about it: 1. It's the C programming language represented as SSA form and with some of the UB in the C spec given a strict definition. 2. It's a low level representation. It's suitable for lowering other languages to. Theoretically, you could lower anything to it since it's Turing-complete. Practically, it's only suitable for lowering sufficie…

> 1. It's the C programming language represented as SSA form and with some of the UB in the C spec given a strict definition.

This is becoming steadily less true over time, as LLVM IR is growing somewhat more divorced from C/C++, but that's probably a good way to start thinking about it if you're comfortable with C's corner case semantics.

(In terms of frontends, I've seen "Rust needs/wants this" as much as Clang these days, and Flang and Julia are also pretty relevant for some things.)

There's currently a working group in LLVM on building better, LLVM-based semantics, and the current topic du jour of that WG is a byte type proposal.

Re: LLVM: The bad parts

#38

Post by anarazel »

nikic wrote: post #35
anarazel wrote: post #30

FWIW, the article says "Frontends are somewhat insulated from this because they can use the largely stable C API." but that's not been my/our experience. There are parts of the API that are somewhat stable, but other parts (e.g. Orc) that change wildly.

Yes, the Orc C API follows different rules from the rest of the C API ( https://github.com/llvm/llvm-project/blob/501416a755d1b85ca1... ).

I know, but even if it's not breaking promises, the constant stream of changes still makes it still rather painful to utilize LLVM. Not helped by the fact that unless you embed LLVM you have to deal with a lot of different LLVM versions out there...

Re: LLVM: The bad parts

#39

Post by pizlonator »

jcranmer wrote: post #37
pizlonator wrote: post #32

Earlier quoted context omitted.

> like the union of different languages No. Here are two good ways to think about it: 1. It's the C programming language represented as SSA form and with some of the UB in the C spec given a strict definition. 2. It's a low level representation. It's suitable for lowering other languages to. Theoretically, you could lower anything to it since it's Turing-complete. Practically, it's only suitable for lowering sufficie…

> 1. It's the C programming language represented as SSA form and with some of the UB in the C spec given a strict definition. This is becoming steadily less true over time, as LLVM IR is growing somewhat more divorced from C/C++, but that's probably a good way to start thinking about it if you're comfortable with C's corner case semantics. (In terms of frontends, I've seen "Rust needs/wants this" as much as Clang the…

> This is becoming steadily less true over time, as LLVM IR is growing somewhat more divorced from C/C++, but that's probably a good way to start thinking about it if you're comfortable with C's corner case semantics.

First of all, you're right. I'm going to reply with amusing pedantry but I'm not really disagreeing

I feel like in some ways LLVM is becoming more like C-in-SSA...

> and the current topic du jour of that WG is a byte type proposal.

That's a case of becoming more like C! C has pointer provenance and the idea that byte copies can copy "more" than just the 8 bits, somehow.

(The C provenance proposal may be in a state where it's not officially part of the spec - I'm not sure exactly - but it's effectively part of the language in the sense that a lot of us already consider it to be part of the language.)

Re: LLVM: The bad parts

#40

Post by jcranmer »

pizlonator wrote: post #39
jcranmer wrote: post #37

Earlier quoted context omitted.

> 1. It's the C programming language represented as SSA form and with some of the UB in the C spec given a strict definition. This is becoming steadily less true over time, as LLVM IR is growing somewhat more divorced from C/C++, but that's probably a good way to start thinking about it if you're comfortable with C's corner case semantics. (In terms of frontends, I've seen "Rust needs/wants this" as much as Clang the…

> This is becoming steadily less true over time, as LLVM IR is growing somewhat more divorced from C/C++, but that's probably a good way to start thinking about it if you're comfortable with C's corner case semantics. First of all, you're right. I'm going to reply with amusing pedantry but I'm not really disagreeing I feel like in some ways LLVM is becoming more like C-in-SSA... > and the current topic du jour of tha…

The C pointer provenance is still in TS form and is largely constructed by trying to retroactively justify the semantics of existing compilers (which all follow some form of pointer provenance, just not necessarily coherently). This is still an area where we have a decent idea of what we want the semantics to be but it's challenging to come up with a working formalization.

I'd have to double-check, but my recollection is that the current TS doesn't actually require that you be able to implement user-written memcpy, rather it's just something that the authors threw their hands up and said "we hope compilers support this, but we can't specify how." In that sense, byte type is going beyond what C does.

Post reply on HN