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

21–30 of 81 posts

Re: LLVM: The bad parts

#21

Post by fooker »

pizlonator wrote: post #18
fooker wrote: post #17

Earlier quoted context omitted.

Remat can produce a performance boost even when everything has a register. Admittedly, this comes up more often in non-CPU backends.

> Remat can produce a performance boost even when everything has a register. Can you give an example?

Rematerializing 'safe' computation from across a barrier or thread sync/wait works wonders.

Also loads and stores and function calls, but that's a bit finicky to tune. We usually tell people to update their programs when this is needed.

Re: LLVM: The bad parts

#22

Post by pizlonator »

fooker wrote: post #21
pizlonator wrote: post #18

Earlier quoted context omitted.

> Remat can produce a performance boost even when everything has a register. Can you give an example?

Rematerializing 'safe' computation from across a barrier or thread sync/wait works wonders. Also loads and stores and function calls, but that's a bit finicky to tune. We usually tell people to update their programs when this is needed.

> Rematerializing 'safe' computation from across a barrier or thread sync/wait works wonders.

While this is literally "rematerialization", it's such a different case of remat from what I'm talking about that it should be a different phase. It's optimizing for a different goal.

Also feels very GPU specific. So I'd imagine this being a pass you only add to the pipeline if you know you're targeting a GPU.

> Also loads and stores and function calls, but that's a bit finicky to tune. We usually tell people to update their programs when this is needed.

This also feels like it's gotta be GPU specific.

No chance that doing this on a CPU would be a speed-up unless it saved you reg pressure.

Re: LLVM: The bad parts

#23

Post by loeg »

ggggffggggg wrote: post #20

> This is somewhat unsurprising, as code review … may not provide immediate value to the person reviewing (or their employer). If you get “credit” for contributing when you review, maybe people (and even employers, though that is perhaps less likely) would find doing reviews to be more valuable. Not sure what that looks like; maybe whatever shows up in GitHub is already enough.

Honestly, the same phenomenon is a problem inside companies as well. My employer credits review quality and quantity relatively well (i.e., in annual performance review), but it still isn't a strong enough motivator to really get the rate up to a satisfactory level.

Re: LLVM: The bad parts

#24

Post by [deleted] »

ksec wrote: post #19

>Compilation time I remember part of the selling point of LLVM during its early stage was compilation time being so much faster than GCC. LLVM started about 15 years after GCC. Considering LLVM is 23 years old already. I wonder if something new again will pop up.

[deleted]

Re: LLVM: The bad parts

#25

Post by bigstrat2003 »

neuroelectron wrote: post #3

It's amazing to me that this is trusted to build so much of software. It's basically impossible to audit yet Rust is supposed to be safe. It's a pipe dream that it will ever be complete or Rust will deprecate it. I think infinite churn is the point.

> I think infinite churn is the point.

That would require the LLVM devs to be stupid and/or evil. As that is not the case, your supposition is not true either. They might be willing to accept churn in the service of other goals, but they don't have churn as a goal unto itself.

Re: LLVM: The bad parts

#26

Post by circuit10 »

ksec wrote: post #19

>Compilation time I remember part of the selling point of LLVM during its early stage was compilation time being so much faster than GCC. LLVM started about 15 years after GCC. Considering LLVM is 23 years old already. I wonder if something new again will pop up.

A few months ago someone wrote a much faster -O0 backend for LLVM, though it seems it didn't get much attention upstream: https://discourse.llvm.org/t/tpde-llvm-10-20x-faster-llvm-o0...

Discussion: https://news.ycombinator.com/item?id=45072481

There are also codegen projects that don't use LLVM IR that are faster like Cranelift: https://github.com/bytecodealliance/wasmtime/tree/main/crane...

Re: LLVM: The bad parts

#28

Post by weinzierl »

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 LLVM IR not being stable between versions had given way to understanding that this freedom was necessary.

Do you think I misunderstood?

Re: LLVM: The bad parts

#29

Post by enos_feedler »

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…

This take makes sense in the context of MLIR creation which introduces dialects which are namespaces within the IR. Given it was created by Chris Lattner I would guess he saw these problems with LLVM as well.

Re: LLVM: The bad parts

#30

Post by anarazel »

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.
Post reply on HN