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

41–50 of 81 posts

Re: LLVM: The bad parts

#41

Post by weinzierl »

pizlonator wrote: post #32
weinzierl wrote: post #28

Earlier quoted context omitted.

"LLVM IR is actually remarkably stable these days." I'm by no means an LLVM expert but my take away from when I played with it a couple of years ago was that it is more like the union of different languages. Every tool and component in the LLVM universe had its own set of rules and requirements for the LLVM IR that it understands. The IR is more like a common vocabulary than a common language. My bewilderment about L…

> like the union of different languages No. Here are two good ways to think about it: 1. It's the C programming language represented as SSA form and with some of the UB in the C spec given a strict definition. 2. It's a low level representation. It's suitable for lowering other languages to. Theoretically, you could lower anything to it since it's Turing-complete. Practically, it's only suitable for lowering sufficie…

Thanks for your detailed answer. You encouraged me to give it another try and have closer look this time.

Re: LLVM: The bad parts

#42

Post by pja »

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?

Re: LLVM: The bad parts

#43

Post by pizlonator »

jcranmer wrote: post #40
pizlonator wrote: post #39

Earlier quoted context omitted.

> This is becoming steadily less true over time, as LLVM IR is growing somewhat more divorced from C/C++, but that's probably a good way to start thinking about it if you're comfortable with C's corner case semantics. First of all, you're right. I'm going to reply with amusing pedantry but I'm not really disagreeing I feel like in some ways LLVM is becoming more like C-in-SSA... > and the current topic du jour of tha…

The C pointer provenance is still in TS form and is largely constructed by trying to retroactively justify the semantics of existing compilers (which all follow some form of pointer provenance, just not necessarily coherently). This is still an area where we have a decent idea of what we want the semantics to be but it's challenging to come up with a working formalization. I'd have to double-check, but my recollectio…

> The C pointer provenance is still in TS form and is largely constructed by trying to retroactively justify the semantics of existing compilers

That's my understanding too

> I'd have to double-check, but my recollection is that the current TS doesn't actually require that you be able to implement user-written memcpy, rather it's just something that the authors threw their hands up and said "we hope compilers support this, but we can't specify how."

That's also my understanding

> In that sense, byte type is going beyond what C does.

I disagree, but only because I probably define "C" differently than you.

"C", to me, isn't what the spec describes. If you define "C" as what the spec describes, then almost zero C programs are "C". (Source: in the process of making Fil-C, I experimented with various points on the spectrum here and have high confidence that to compile any real C program you need to go far beyond what the spec promises.)

To me, when we say "C", we are really talking about:

- What real C programs expect to happen.

- What real C compilers (like LLVM) make happen.

In that sense, the byte type is a case of LLVM hardening the guarantee that it already makes to real C programs.

So, LLVM having a byte type is a necessary component of LLVM supporting C-as-everyone-practically-it.

Also, I would guess that we wouldn't be talking about the byte type if it wasn't for C. Type safe languages with well-defined semantics have no need for allowing the user to write a byte-copy loop that does the right thing if it copies data of arbitrary type

(Please correct me if I'm wrong, this is fun)

Re: LLVM: The bad parts

#44

Post by apitman »

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.

Re: LLVM: The bad parts

#45

Post by MeetingsBrowser »

apitman wrote: post #44

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.

What language do you typically use?

Re: LLVM: The bad parts

#46

Post by pklausler »

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

Re: LLVM: The bad parts

#47

Post by nikic »

pklausler wrote: post #46

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

That was ambiguously phrased. The point I was trying to make here is that we don't have the situation that is very common for open-source projects, where a project might nominally have a 100 contributors, but in reality it's one person doing 95% of the changes.

LLVM of course has plenty of contributors that only ever landed one change, but the thing that matters for project health is that that the group of "top contributors" is fairly large.

(And yes, this does differ by subproject, e.g. lld is an example of a subproject where one contributor is more active than everyone else combined.)

Re: LLVM: The bad parts

#48

Post by hoyhoy »

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

Re: LLVM: The bad parts

#49

Post by pklausler »

nikic wrote: post #47
pklausler wrote: post #46

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

That was ambiguously phrased. The point I was trying to make here is that we don't have the situation that is very common for open-source projects, where a project might nominally have a 100 contributors, but in reality it's one person doing 95% of the changes. LLVM of course has plenty of contributors that only ever landed one change, but the thing that matters for project health is that that the group of "top contr…

There may be a difference of degree here, but not a difference of kind.

Re: LLVM: The bad parts

#50

Post by simonask »

anonymous908213 wrote: post #34
phplovesong wrote: post #16

Earlier quoted context omitted.

Also OCaml. Having a own compiler is THE way for language development. IMHO.

Personally I think a happy medium is to compile to C99. Then, after your own compiler's high-level syntax transformation pass, you can pass it through the Tiny C Compiler which is somewhere on the order of ~10x faster than Clang -O0. When you need performance optimizations at the cost of build speed, or to support a compilation target that TCC does not, you can freely switch to compiling with Clang, getting much of t…

That might be convenient if your language has semantics that map well-ish to C99 semantics. But C is a really messy language with lots of little quirks. For example, Rust code would compile to something slower if it had to use C as an intermediate representation.

Also, compiled languages want accurate and rich debug info. All of that information would be lost.

Post reply on HN