4 ms·

I understand thal LLVM implements the C++11 memory model, which specifies the termination requirements for non-side effects loops.

tialaramex 3y ago
It's true that C++ specifies this as part of its forward progress guarantees and that's likely how it infected LLVM, but I'd deny that LLVM's rather sparse documentation of their IR lowering says basically "Ooops, we actually are only suitable as the core of a C++ compiler" was part of their intent, especially since LLVM substantially pre-dates Clang... Lattner started work on Clang in 2006, but LLVM is from 2000.. And sure enough when the Rust project finds bugs in LLVM related to this, there is no "Oh you can't have the semantics we documented, we actually provide exactly whatever C++ says instead for some reason". Sometimes it's a doc bug but most often the problem is that as usual the optimisation passes assumed something that's just not true outside of C++.
- gpderetta 3y ago
  I have no idea where's the formal spec for rust, but there's this: https://doc.rust-lang.org/nomicon/atomics.html https://doc.rust-lang.org/nomicon/atomics.html Edit: LLVM predates clang, but dragon egg was a thing. In any case, before C++11 there was no memory model suitable for a system language[1], so it was the obvious solution. [1] POSIX, OpenMP and the linux kernel all had memory models, but they were either underspecified, not sufficient or both.
  - tialaramex 3y ago
    That's telling you that Rust has the C++ Memory Ordering rules, not that it has the C++ Forward Progress guarantee. C likewise has the C++ Memory Ordering, but not its Forward Progress guarantee. As I wrote earlier, C has infinite loops, they're spelled the way you'd obviously write them in C or C++, but in C they're supposed to actually work (whereas in C++ they are UB). Rust is only different here syntactically, the semantic feature is identical to C's choice.

tialaramex 3y ago

It's true that C++ specifies this as part of its forward progress guarantees and that's likely how it infected LLVM, but I'd deny that LLVM's rather sparse documentation of their IR lowering says basically "Ooops, we actually are only suitable as the core of a C++ compiler" was part of their intent, especially since LLVM substantially pre-dates Clang... Lattner started work on Clang in 2006, but LLVM is from 2000.. And sure enough when the Rust project finds bugs in LLVM related to this, there is no "Oh you can't have the semantics we documented, we actually provide exactly whatever C++ says instead for some reason". Sometimes it's a doc bug but most often the problem is that as usual the optimisation passes assumed something that's just not true outside of C++.

gpderetta 3y ago
I have no idea where's the formal spec for rust, but there's this: https://doc.rust-lang.org/nomicon/atomics.html https://doc.rust-lang.org/nomicon/atomics.html Edit: LLVM predates clang, but dragon egg was a thing. In any case, before C++11 there was no memory model suitable for a system language[1], so it was the obvious solution. [1] POSIX, OpenMP and the linux kernel all had memory models, but they were either underspecified, not sufficient or both.
- tialaramex 3y ago
  That's telling you that Rust has the C++ Memory Ordering rules, not that it has the C++ Forward Progress guarantee. C likewise has the C++ Memory Ordering, but not its Forward Progress guarantee. As I wrote earlier, C has infinite loops, they're spelled the way you'd obviously write them in C or C++, but in C they're supposed to actually work (whereas in C++ they are UB). Rust is only different here syntactically, the semantic feature is identical to C's choice.