News for hackers. Stuff that matters.
Re:LLVM: The Bad Parts by ksec on Monday January 12, 2026 @11:58AM (#46591133)
>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 by circuit10 on Monday January 12, 2026 @01:01PM (#46591955)
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 by mungaihaha on Monday January 12, 2026 @10:31PM (#46597057)
> Considering LLVM is 23 years old already. I wonder if something new again will pop up

LLVM is actually really really good at what it does (compiling c/c++ code). Not perfect, but good enough that it would take tens of thousands of competent man hours to match it

Re:LLVM: The Bad Parts by pjmlp on Tuesday January 13, 2026 @05:39AM (#46599312)
If it wasn't for Apple wanting to get rid of GCC due to licensing, and Google as well on Android, LLVM would have remained like Andrew Compiler Toolkit, MSR Phoenix, and similar endevours, another compiler development research project at Illinois university.

Thus what would be the commercial reason to support LLVM's sucessor, especially since the companies that were responsible for LLVM going mainstream, are happy with current C and C++ support, mostly using LLVM for other programming language frontends?

Re:LLVM: The Bad Parts by flamedoge on Tuesday January 13, 2026 @06:51AM (#46599830)
non-C/C++ centric, performant compiler maybe. Aliasing support in C is pretty limited and a performant langauge like fortran and more modern equivalents may seek more efficient, concise IR for compiler with less comparable overhead from LLVM.
Re:LLVM: The Bad Parts by pjmlp on Tuesday January 13, 2026 @07:12AM (#46599987)
Yeah, but those already exist as plenty of compiled languages are bootstraped already, thus I don't see the business value of LLVM-vNext.

One might argue GraalVM could be such one, however it has an history that traces back to SunLabs Maxime VM, it is focused on Java ecosystem, serverless deployments into Oracle Cloud, and for compiler development the target audience doesn't overlap with LLVM folks (C++ vs Java tooling).