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

61–70 of 81 posts

Re: LLVM: The bad parts

#61

Post by mungaihaha »

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.

> 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

#62

Post by Panzerschrek »

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.

Re: LLVM: The bad parts

#64

Post by LeFantome »

hoyhoy wrote: post #48

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 availa…

Do Chimera Linux or Mandriva not have LLVM working out of the box in your view?

I mean, Chimera Linux is pretty LLVM native.

Re: LLVM: The bad parts

#66

Post by r2vcap »

sixthDot wrote: post #65

Also the C API is a bit the poor child. Plenty of useful options (or even opt passes !) are not available.

I think a large part of this comes from the fact that the expressiveness of LLVM’s C++ APIs does not translate well into a “plain old C” style interface. Many of the abstractions and extension points are simply awkward or impractical to expose in C.

On top of that, there is little incentive for contributors to invest in the C API: most LLVM users and developers interact with the C++ API directly, so new features and options tend to be added there first, and often exclusively. As a result, the C API inevitably lags behind and remains a second-class citizen.

Re: LLVM: The bad parts

#67

Post by mort96 »

hoyhoy wrote: post #48

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 availa…

Wait is THAT why I've been unable to build compiler-rt on macOS? Do you have a link?

Re: LLVM: The bad parts

#68

Post by anonymousDan »

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.

Re: LLVM: The bad parts

#69

Post by tvali »

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.

Re: LLVM: The bad parts

#70

Post by pjmlp »

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.

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?

Post reply on HN