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

51–60 of 81 posts

Re: LLVM: The bad parts

#51

Post by tubs »

simonask wrote: post #50
anonymous908213 wrote: post #34

Earlier quoted context omitted.

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.

You can track debug symbol through c. It’s just one of many layers debug info gets tracked through.

Re: LLVM: The bad parts

#52

Post by uecker »

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…

bytewise copy just works with the TS. What it does not support is tracking provenance across the copy and doing optimization based on this. What we hope is that compilers drop these optimizations, because they are unsound.

Re: LLVM: The bad parts

#53

Post by uecker »

pizlonator wrote: post #43
jcranmer wrote: post #40

Earlier quoted context omitted.

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…

The C standard has a conformance model that distinguishes between "strictly conforming" and "conforming" C programs. Almost zero C programs are strictly conforming, but many are conforming.

Re: LLVM: The bad parts

#54

Post by lhames »

anarazel wrote: post #38
nikic wrote: post #35

Earlier quoted context omitted.

Yes, the Orc C API follows different rules from the rest of the C API ( https://github.com/llvm/llvm-project/blob/501416a755d1b85ca1... ).

I know, but even if it's not breaking promises, the constant stream of changes still makes it still rather painful to utilize LLVM. Not helped by the fact that unless you embed LLVM you have to deal with a lot of different LLVM versions out there...

FWIW eventual stability is a goal, but there's going to be more churn as we work towards full arbitrary program execution (https://www.youtube.com/watch?v=qgtA-bWC_vM covers some recent progress).

If you're looking for stability in practice: the ORC LLJIT API is your best bet at the moment (or sticking to MCJIT until it's removed).

Re: LLVM: The bad parts

#55

Post by adgjlsfhk1 »

pja wrote: post #42

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…

If you don't build with parallelism and have a couple gigs of swap available, it should work (although you might need to set some command line flags to use the right linker settings).

Re: LLVM: The bad parts

#56

Post by adgjlsfhk1 »

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…

C is a pretty horrible compilation target. Avoiding UB when generating C code is really tough.

Re: LLVM: The bad parts

#57

Post by cardanome »

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.

QBE might be more to your liking: https://c9x.me/compile/

It is used in the Hare language

Re: LLVM: The bad parts

#58

Post by neuroelectron »

bigstrat2003 wrote: post #25
neuroelectron wrote: post #3

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.

> I think infinite churn is the point. That would require the LLVM devs to be stupid and/or evil. As that is not the case, your supposition is not true either. They might be willing to accept churn in the service of other goals, but they don't have churn as a goal unto itself.

How can you make that assumption?

Re: LLVM: The bad parts

#59

Post by cogman10 »

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…

Gentoo is calling you ;)

https://wiki.gentoo.org/wiki/LLVM

Re: LLVM: The bad parts

#60

Post by mungaihaha »

pja wrote: post #42

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…

> 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

Post reply on HN