I remember the time I did dive in LLVM, object orientation was so much aggressive that you have to embrace the whole object oriented model to start to have a chance to understand what the code is actually doing.
LLVM: The bad parts
71–80 of 81 posts
Re: LLVM: The bad parts
#72>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.
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 wi…
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
#73Earlier quoted context omitted.
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 wi…
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.
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).
Re: LLVM: The bad parts
#74My main concern with LLVM is that it adds 30+ million lines of code dependency to any language that relies on it. Part of the reason I'm not ready to go all in on Rust is that I'm not willing to externalize that much complexity in the programs I make.
The Rust compiler also uses LLVM right ?
Re: LLVM: The bad parts
#75Six years ago I was building LLVM pretty regularly on an 8GB Dell 9360 laptop whilst on a compiler related contract. (Still have it actually - that thing is weirdly indestructible for a cheap ultrabook.) Build time wasn’t great, but it was tolerable, so long as you reduced link parallelism to squeeze inside the memory constraints. Is it still possible to compile LLVM on such a machine, or is 8Gb no longer workable at…
> or is 8Gb no longer workable llvm compiles in less than an hour on my old m1 mac in all the build configurations I have tried so far
Pretty much the same then - good news!
Re: LLVM: The bad parts
#76Comptimes aee an issue, not only for LLVM itself, but also for users, as a prime example: Rust. Rust has horrible comptimes for anything larger, what makes its a real PITA to use.
I think that’s primarily a Rust issue, not an LLVM issue. LLVM is at least competitive performance-wise in every case I’ve used it, and is usually the fastest option (given a specific linker behavior) outright. That’s especially true on larger code bases (e.g. chromium, or ZFS).
Rust is also substantially faster to compile than it was a few years ago, so I have some hope for improvements in that area as well.
Re: LLVM: The bad parts
#77I asked the guy working on compiler-rt to change one boolean so the LLVM 18 build would work on macOS, and he locked the whole issue down as "heated" and it's still not fixed four years later. I love LLVM though. clang-tidy, ASAN, UBSAN, LSAN, MSAN, and TSAN are AMAZING. If you are coding C and C++ and NOT using clang-tidy, you are doing it wrong. My biggest problem with LLVM rn is that -fbounds-safety is only availa…
> What would be amazing is if some distro would just ship native LLVM with all the things working out of the box.
Omarchy could/should do this, nice low-hanging fruit.
@dhh, if you're listening, the other good thing Omarchy could do is support the VFX Reference Platform specs maintained by the ASWF. That would bring in all of the Linux-based VFX software to Omarchy in a clean way.
Re: LLVM: The bad parts
#78Is there any implicit understanding in the community that byte types will inevitably be added to LLVM? I see that there has been a recent GSOC effort ( https://blog.llvm.org/posts/2025-08-29-gsoc-byte-type/ ) but it's unclear whether this has resolved most of the issues or is still an open research problem.
> Is there any implicit understanding in the community that byte types will inevitably be added to LLVM?
Among the people who are familiar with such things, yes. An RFC on the topic will be posted in the near future.
Re: LLVM: The bad parts
#79My main concern with LLVM is that it adds 30+ million lines of code dependency to any language that relies on it. Part of the reason I'm not ready to go all in on Rust is that I'm not willing to externalize that much complexity in the programs I make.
The Rust compiler also uses LLVM right ?
mainly, but it also supports alternative codegen backends (cranelift, rustc_codegen_gcc)
Re: LLVM: The bad parts
#80My main concern with LLVM is that it adds 30+ million lines of code dependency to any language that relies on it. Part of the reason I'm not ready to go all in on Rust is that I'm not willing to externalize that much complexity in the programs I make.
Does it? One of LLVM's main selling points is modularisation. You can mix and match components; you don't have to depend on the entire monorepo