Don't compute FnAbi for LLVM intrinsics - #160077
Conversation
|
Some changes occurred to the CTFE machinery These commits modify compiler targets. Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
|
|
|
I guess this finishes my quest of getting rid of
There is still cleanup that can be done, but at least this wildly wrong combination is gone. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| fn test_f32x2(a: f32x2); | ||
| fn test_f32x2_arr(a: f32x2); | ||
| fn test_simd(a: Simd<i32, 4>); | ||
| fn test_simd_unaligned(a: Simd<i32, 3>); |
There was a problem hiding this comment.
There is no way to test this specific case anymore it seems. LLVM doesn't accept PackedSimd on intrinsics, extern "unadjusted" requires LLVM intrinsics and any other ABI doesn't pass non-power-of-2 vectors as { [3 x i32] }.
7358ce7 to
eacedff
Compare
commented
Jul 31, 2026
|
Looks like compiler-builtins still has some |
ef2938a to
e2873a0
Compare
commented
Jul 31, 2026
|
cc @tgross35 |
left a comment
•
There was a problem hiding this comment.
interpreter changes mostly LGTM.
compiler-builtins changes will need a review by @tgross35 .
| #[cfg_attr(target_os = "uefi", unadjusted_on_win64)] | ||
| #[cfg(not(all(target_os = "uefi", target_arch = "x86_64")))] | ||
| pub extern "C" fn __floattisf(i: i128) -> f32 { | ||
| int_to_float::signed(i, int_to_float::u128_to_f32_bits) | ||
| } | ||
|
|
||
| #[cfg_attr(target_os = "uefi", unadjusted_on_win64)] | ||
| #[cfg(all(target_os = "uefi", target_arch = "x86_64"))] | ||
| pub extern "C" fn __floattisf(lo: u64, hi: u64) -> f32 { | ||
| int_to_float::signed((i128::from(hi) << 64) | i128::from(lo), int_to_float::u128_to_f32_bits) | ||
| } | ||
|
|
||
| #[cfg(not(all(target_os = "uefi", target_arch = "x86_64")))] | ||
| pub extern "C" fn __floattidf(i: i128) -> f64 { | ||
| int_to_float::signed(i, int_to_float::u128_to_f64_bits) | ||
| } | ||
|
|
||
| #[cfg(all(target_os = "uefi", target_arch = "x86_64"))] | ||
| pub extern "C" fn __floattidf(lo: u64, hi: u64) -> f64 { | ||
| int_to_float::signed((i128::from(hi) << 64) | i128::from(lo), int_to_float::u128_to_f64_bits) | ||
| } |
There was a problem hiding this comment.
Do we even need the special casing anymore? i128 has gone through some ABI changes on Windows and it doesn't look like https://github.com/llvm/llvm-project/blob/41322057c3af16d75e239ec6679c6c2bf7aec157/compiler-rt/lib/builtins/floattisf.c#L28 is doing anything special.
There was a problem hiding this comment.
Yes, they still have different ABIs: https://rust.godbolt.org/z/454nczzdr u128 is passed in xmm0 with extern "C", while u64 + u64 is passed in rdx/rcx just like u128 with extern "unadjusted": https://rust.godbolt.org/z/av1f38KrW
There was a problem hiding this comment.
Looking at https://rust.godbolt.org/z/fYMc6b8MP I think that Windows is in harmony; always pass indirectly, return in xmm0. I couldn't get it to emit __muloti4.
UEFI seems to be the one that's weird - if I'm reading right it's usually passed indirectly and returned in rax,rdx, but for the __floattisf libcall it seems to be loading into rcx and rdx? I have no idea where this comes from, it doesn't appear to be in https://github.com/llvm/llvm-project/blob/f532c2d780d3afe589b43cb920fbc445322d47f7/compiler-rt/lib/builtins/floattisf.c#L28 so I wonder if it's an oversight in LLVM.
commented
Aug 3, 2026
|
@rustbot author |
This comment has been minimized.
This comment has been minimized.
d2588c6 to
a457bee
Compare
commented
Aug 4, 2026
|
@rustbot ready |
commented
Aug 4, 2026
|
r=me on the Miri part and the test. |
Co-authored-by: Ralf Jung <post@ralfj.de>
85cb480 to
0417c4e
Compare
commented
Aug 13, 2026
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Rebased, fixed test for LLVM 23 and changed the ABI cfg for |
commented
Aug 13, 2026
|
With this PR @bors r=RalfJung,tgross35 |
commented
Aug 13, 2026
commented
Aug 13, 2026
That makes way more sense, I never understood what "unadjusted" was referring to. Perhaps both names should be accepted and stdarch can migrate in pieces? |
commented
Aug 14, 2026
|
Finished benchmarking commit (a96bde1): comparison URL. Overall result: no relevant changes - no action neededBenchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. @rustbot label: -S-waiting-on-perf -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (primary -3.8%, secondary -1.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 455.615s -> 458.245s (0.58%) |
commented
Aug 16, 2026
|
stdarch is a subtree now so it should be possible to do the rename in one go. |
commented
Aug 20, 2026
|
Opened #161398 for the rename. |
View all comments
They don't have a sensible FnAbi, so the fact that we still compute an FnAbi for them requires us to make the ABI sanity check more lenient than it should be.
r? @RalfJung as all non-trivial changes are in Miri