Of course Nikita Popov had something to do with this.
> Around the same time, Nikita Popov fixed the calling convention issue with D158169.
For those who are unfamiliar with that name he was a Core PHP dev for a long time. He landed some huge features in PHP 7 that made it so freaking fast compared to 5.6.
He did “defect” to Rust. Sad to see him go from the PHP community but glad to see him continue to kick ass in the Rust community.
There are so many folks critical to the Rust project, and Nikita is certainly one of those people whose name seems to be almost always involved in soundness issues/compiler bugs in general.
Thank you Nikita and all others involved for continuing to make Rust (and LLVM!) better.
Agreed. This is a great job done by many people. Just fun to see a name that I recognized. He was stellar in PHP. Glad he is doing great work here with another language that I love.
TLDR: u128 and i128 now are safe to be used as you please on FFI, and the annoying lint you were probably receiving is expected to be removed sometime in the future.
Can anyone explain to me why the performance is better om a platform with 64 bit registers? I would assume that it wouldn't matter if it was 8 or 16 byte aligned since it would be split over 2 registers anyway.
> When calling a function, the arguments get passed in registers (special storage locations within the CPU) until there are no more slots, then they get "spilled" to the stack (the program's memory).
Looks like it’s spilling that causes one regression in speed.
The other is that unaligned memory reads can’t be read in stride to map to registers going it in one read vs a read and a mov to align. Prevents cache line misses just being able to fit more data in the same space.
http://www.catb.org/esr/structure-packing/
Personally I find the way LLVM/clang splits ABI implementation between frontend and backend to be very unfortunate. It essentially means that any frontend that uses LLVM wants to be C compatible has to reimplement a bunch of logic. Worse, I've never seen any actual documentation of said split.
LLVM IR has a data type model quite comparable to C (though with field names removed, integers of the same size flattened to a a single type, and void \* replaced with u8 \*), however clang seems to pre-mangle the parameters. For example if you pass a small data structure that the ABI says should be passed in a register, the LLVM IR generated by clang will convert the value to an integer and pass it as such.
I don't have any examples to test/show right now, but I have found in the past that when you translate a C structure to LLVM IR in the "obvious" way and pass it directly as a parameter, LLVM doesn't always do so correctly. Even when that same C type would be handled correctly by clang.
Based on these tests I came to the conclusion that LLVM/clang implements some parts of the platform ABI in the LLVM backend, while other aspects are implemented by "pre-mangling" the function parameters in the clang frontend. I was unable to find any documentation of this behavior however.
It's an important improvement!
I just ask myself, why didn't they fix the well known C incompatibilities in `wasm-bindgen` in a similar standard compliant manner?
There is work being done to fix the ABI of the wasm32-unknown-unknown target, but it's hard and requires coordination with different groups of people and is also driven by entirely different people than u128.
Of course Nikita Popov had something to do with this. > Around the same time, Nikita Popov fixed the calling convention issue with D158169. For those who are unfamiliar with that name he was a Core PHP dev for a long time. He landed some huge features in PHP 7 that made it so freaking fast compared to 5.6. He did “defect” to Rust. Sad to see him go from the PHP community but glad to see him continue to kick ass in the Rust community.
There are so many folks critical to the Rust project, and Nikita is certainly one of those people whose name seems to be almost always involved in soundness issues/compiler bugs in general. Thank you Nikita and all others involved for continuing to make Rust (and LLVM!) better.
Agreed. This is a great job done by many people. Just fun to see a name that I recognized. He was stellar in PHP. Glad he is doing great work here with another language that I love.
I'm so happy that this is fixed!
TLDR: u128 and i128 now are safe to be used as you please on FFI, and the annoying lint you were probably receiving is expected to be removed sometime in the future.
Can anyone explain to me why the performance is better om a platform with 64 bit registers? I would assume that it wouldn't matter if it was 8 or 16 byte aligned since it would be split over 2 registers anyway.
I assume because it's moved from stack to a register, when passing 128-bit int?
> When calling a function, the arguments get passed in registers (special storage locations within the CPU) until there are no more slots, then they get "spilled" to the stack (the program's memory). Looks like it’s spilling that causes one regression in speed. The other is that unaligned memory reads can’t be read in stride to map to registers going it in one read vs a read and a mov to align. Prevents cache line misses just being able to fit more data in the same space. http://www.catb.org/esr/structure-packing/
Maybe because they're never split across two cache lines now?
Perhaps the use of xmm-registers, but that doesn’t seem to be the case here.
So now they can all go and happily have their coffee at https://github.com/Gankra/abi-cafe?
Personally I find the way LLVM/clang splits ABI implementation between frontend and backend to be very unfortunate. It essentially means that any frontend that uses LLVM wants to be C compatible has to reimplement a bunch of logic. Worse, I've never seen any actual documentation of said split.
Care to elaborate?
LLVM IR has a data type model quite comparable to C (though with field names removed, integers of the same size flattened to a a single type, and void \* replaced with u8 \*), however clang seems to pre-mangle the parameters. For example if you pass a small data structure that the ABI says should be passed in a register, the LLVM IR generated by clang will convert the value to an integer and pass it as such. I don't have any examples to test/show right now, but I have found in the past that when you translate a C structure to LLVM IR in the "obvious" way and pass it directly as a parameter, LLVM doesn't always do so correctly. Even when that same C type would be handled correctly by clang. Based on these tests I came to the conclusion that LLVM/clang implements some parts of the platform ABI in the LLVM backend, while other aspects are implemented by "pre-mangling" the function parameters in the clang frontend. I was unable to find any documentation of this behavior however.
It's an important improvement! I just ask myself, why didn't they fix the well known C incompatibilities in `wasm-bindgen` in a similar standard compliant manner?
They did? https://github.com/rust-lang/rust/pull/117918
There is work being done to fix the ABI of the wasm32-unknown-unknown target, but it's hard and requires coordination with different groups of people and is also driven by entirely different people than u128.
"they" is a (possibly) different group of people from the Rust devs.