Changes to `u128`/`i128` layout in Rust 1.77 and 1.78

https://blog.rust-lang.org/2024/03/30/i128-layout-update.html

by JoshTriplett • 2 years ago

20 2 2 years ago

saghm• 2 years ago

I found this part interesting:

It turns out this isn't because of something that Rust is actively doing incorrectly: layout of primitives comes from the LLVM codegen backend used by both Rust and Clang, among other languages, and it has the alignment for i128 hardcoded to 8 bytes.
Clang uses the correct alignment only because of a workaround, where the alignment is manually set to 16 bytes before handing the type to LLVM. This fixes the layout issue but has been the source of some other minor problems.

For some reason, my mental model of clang and LLVM was that the projects were essentially being worked on by the same group of people, although I'm realizing now that I have no actual knowledge that indicates this is the case other than knowing that clang was the first place I had heard of LLVM from. The fact that an issue could be in LLVM but is partially worked around in clang raises several questions for me:

1. Was this considered a bug by the LLVM developers when it was initially worked around in clang? 2. Would the developers of clang who added the workaround have been able to directly commit a fix in LLVM at the time? 3. When an issue is worked around in the compiler for one LLVM-bas3d language, is there any formal or inform but ongoing communication channels that the developers can use to tell developers of other LLVM-based language in case they also need to work around this?

I'm asking these questions because I don't actually know the answers to them, not to try to make a point. My immediate instinct when hearing that clang worked around this issue but Rust didn't is to think that there either must have been some reason why Rust couldn't (or wouldn't) work around it immediately or that the Rust compiler developers weren't aware of the issue. It's possible that I didn't understand part of the article that answered which of these cases occurred, but I didn't come away from reading it with confidence that I understand fully why 128-bit integers have had this issue for so long (since they were stabilized several years ago if I remember correctly).

pornel• 2 years ago

My impression from Rust/LLVM bugs is that LLVM is only a C++ compiler, except where people complained long and loud enough.

Rust had to add patches to support optimization of Rust allocators (not just malloc and new). Ran into several bugs in mutable aliasing that doesn’t exist in C++ and is very rudimentary in C. Spent seven years fighting with miscompilations due to a C++ rule that infinite loops are UB. Had to implement custom float to int casts to avoid C UB, and so on.

Changes to `u128`/`i128` layout in Rust 1.77 and 1.78

Related Stories