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

11–20 of 81 posts

Re: LLVM: The bad parts

#11

Post by pornel »

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.

Rust does its own testing, and regularly helps fix issues in LLVM (which usually also benefits clang users and other LLVM languages).

Optimizing compilers are basically impossible to audit, but there are tools like alive2 for checking them.

Re: LLVM: The bad parts

#13

Post by fooker »

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…

There is a rematerialize pass, there is no real reason to couple it with register allocation. LLVM regalloc is already somewhat subpar.

What would be neat is to expose all right knobs and levers so that frontend writers can benchmark a number of possibilities and choose the right values.

I can understand this is easier said than done of course.

Re: LLVM: The bad parts

#14

Post by pizlonator »

fooker wrote: post #13
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…

There is a rematerialize pass, there is no real reason to couple it with register allocation. LLVM regalloc is already somewhat subpar. What would be neat is to expose all right knobs and levers so that frontend writers can benchmark a number of possibilities and choose the right values. I can understand this is easier said than done of course.

> There is a rematerialize pass, there is no real reason to couple it with register allocation

The reason to couple it to regalloc is that you only want to remat if it saves you a spill

Re: LLVM: The bad parts

#16

Post by phplovesong »

hu3 wrote: post #8
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.

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.

Re: LLVM: The bad parts

#17

Post by fooker »

pizlonator wrote: post #14
fooker wrote: post #13

Earlier quoted context omitted.

There is a rematerialize pass, there is no real reason to couple it with register allocation. LLVM regalloc is already somewhat subpar. What would be neat is to expose all right knobs and levers so that frontend writers can benchmark a number of possibilities and choose the right values. I can understand this is easier said than done of course.

> There is a rematerialize pass, there is no real reason to couple it with register allocation The reason to couple it to regalloc is that you only want to remat if it saves you a spill

Remat can produce a performance boost even when everything has a register.

Admittedly, this comes up more often in non-CPU backends.

Re: LLVM: The bad parts

#18

Post by pizlonator »

fooker wrote: post #17
pizlonator wrote: post #14

Earlier quoted context omitted.

> There is a rematerialize pass, there is no real reason to couple it with register allocation The reason to couple it to regalloc is that you only want to remat if it saves you a spill

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?

Re: LLVM: The bad parts

#19

Post by ksec »

>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.

Re: LLVM: The bad parts

#20

Post by ggggffggggg »

> 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.

Post reply on HN