by pizlonator
3 subcomments
- 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 the problem here is necessarily licm. It might be that regalloc needs to be taught to rematerialize
- I 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 available on Xcode/AppleClang and not LLVM Clang. MSAN and LSAN are only available on LLVM and not Xcode/AppleClang. Also Xcode doesn't ship clang-tidy, clang-format, or llvm-symbolizer. It's kind of a mess on macOS rn. I basically rolled my own darwin LLVM for LSAN and clang-tidy support.
The situation on Linux is even weirder. RHEL doesn't ship libcxx, but Fedora does ship it. No distro has libcxx instrumented for MSAN at the moment which means rolling your own.
What would be amazing is if some distro would just ship native LLVM with all the things working out of the box. Fedora is really close right now, but I still have to build compiler-rt manually for MSAN support..
- Given some of the discussions I've been stuck in over the past couple of weeks, one of the things I especially want to see built out for LLVM is a comprehensive executable test suite that starts not from C but from LLVM IR. If you've ever tried working on your own backend, one of the things you notice is there's not a lot of documentation about all of the SelectionDAG stuff (or GlobalISel), and there is also a lot of semi-generic "support X operation on top of Y operation if X isn't supported." And the precise semantics of X or Y aren't clearly documented, so it's quite easy to build the wrong thing.
by ggggffggggg
1 subcomments
- > 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.
- Six 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 all?
- >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.
by phplovesong
1 subcomments
- Comptimes 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.
- https://tatsu.readthedocs.io/en/stable/ - this was my result to find lightweight syntax parsers. LLVM: in my experience, to play with little languages or ideas, such as additional tag, is so heavy-weight that it's as hard to learn as Isabelle Proof Assistant; large systems are interesting, but it's worth mentioning that 99% of the functionality could be often 1% of the API.
- 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.
by pklausler
1 subcomments
- > There are thousands of contributors and the distribution is relatively flat (that is, it’s not the case that a small handful of people is responsible for the majority of contributions.)
This certainly varies across different parts of llvm-project. In flang, there's very much a "long tail". 80% of its 654K lines are attributed to the 17 contributors responsible for 1% or more of them, according to "git blame", out of 355 total.
- My 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.
by anonymousDan
1 subcomments
- Is 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.
by Panzerschrek
0 subcomment
- ABI / calling convention handling - that's exactly my pain. As compiler developer I need to manage arguments passing in my compiler frontend code myself, which sometimes even requires register counting.
- Hey Nikita, if you're reading this, Thank You! for your contributions to PHP!
We miss you!
by Panzerschrek
0 subcomment
- LLVM also has (in my opinion) no capacity to review issues. None of the issues I have created were addressed, including a couple of really painful bugs.
- Also the C API is a bit the poor child. Plenty of useful options (or even opt passes !) are not available.
- 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.
- [dead]
by neuroelectron
3 subcomments
- 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.
Hacker News