LLVM ist a mess

Posted Mar 17, 2024 16:32 UTC (Sun) by tialaramex (subscriber, #21167)
In reply to: LLVM ist a mess by khim
Parent article: Cranelift code generation comes to Rust

In particular though LLVM's IR has a lot of places where either they say "We do X" but actually "Oh, we just assumed C++ even though that's not what we wrote" or they just don't explain and when you ask "Um, I guess it's whatever C++ requires". Part of this leaks from Clang and has been significantly corrected by the competing requirements from the Rust compiler team but part of it is clearly more intrinsic to LLVM as a project - they have people who think in C++ when they're supposed to be thinking in terms of LLVM's IR. There's a sloppiness that I'd expect from C++ people and I think is less prevalent for Cranelift.

I think "We assumed C++" is a problem for a research project too. Lots of interesting new work from the last few decades can't happen if you're just "assuming C++" everywhere, what you get out is "Oh well, apparently it's impossible to do better than C++" because you've assumed that's all that's possible.

to post comments

LLVM ist a mess

Posted Mar 17, 2024 17:49 UTC (Sun) by farnz (subscriber, #17727) [Link] (2 responses)

And even when they didn't assume C++, there's often been bugs that boil down to "Clang doesn't use this much, therefore it's not routinely tested and there's lot of lurking bugs"; see the fun Rust has had trying to use noalias on references, where because the matching Clang feature (the C99 restrict type qualifier) is rarely used correctly, miscompilations by LLVM traceable to noalias in LLVM IR kept blocking Rust from using it for Rust references (which definitionally can't alias each other).

LLVM ist a mess

Posted Mar 17, 2024 19:09 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

Is LLVM written in C++? Should they re-write it in Rust?

:-))

Cheers,
Wol

LLVM ist a mess

Posted Mar 17, 2024 19:53 UTC (Sun) by farnz (subscriber, #17727) [Link]

Implementation language isn't at the root of this; the underlying issue is that LLVM IR's semantics aren't (yet) formally defined, but instead rely on informal reasoning throughout LLVM. As a consequence, it's intractable to verify that LLVM actually implements the claimed semantics, and it's not reasonable to write test cases that validate the LLVM IR semantics are met in edge cases, since we don't actually know what the edge cases are.

There's efforts afoot to fully define LLVM IR semantics formally, and one of the biggest outputs those efforts are having (at the moment) is finding bugs in existing LLVM functionality, where existing LLVM code assumes opposing meanings (that both fit the informally defined semantics) for the same LLVM IR construct in different places.