target_features: sse (or at least avx2) is incompatible with soft-float ABI - #160302
target_features: sse (or at least avx2) is incompatible with soft-float ABI#160302RalfJung wants to merge 2 commits into
Conversation
|
r? @khyperia rustbot has assigned @khyperia. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
r? @workingjubilee or @dianqk |
|
|
|
Hm unfortunately it seems like LLVM does not crash on all functions with #[unsafe(no_mangle)]
#[target_feature(enable = "avx2")]
pub fn foobar(x: __m256i, y: __m256i) -> __m256i {
_mm256_or_si256(x, y)
}So we may have to add an FCW for this after all. @tarcieri do you know which function is causing the trouble in dalek-cryptography/curve25519-dalek#601? All we know is that it's somewhere in poly1305... |
|
Okay I have a reproducer: #![no_std]
use core::arch::x86_64::*;
#[unsafe(no_mangle)]
#[target_feature(enable = "avx2")]
pub fn foobar(ptr: *const __m256i) -> __m256i { unsafe {
let key = _mm256_loadu_si256(ptr);
_mm256_and_si256(
_mm256_permutevar8x32_epi32(key, _mm256_set_epi32(3, 7, 2, 6, 1, 5, 0, 4)),
_mm256_set_epi32(0, -1, 0, -1, 0, -1, 0, -1),
)
}} |
58062d1 to
21a23e9
Compare
|
I don't know these features on x86, but the PR seems reasonable to me. |
|
With Nikita on vacation, who might know which features LLVM supports on x86 in combination with But I guess we can also just warn about all vector features (as this PR does now) and if we get issues saying sse actually works fine we can always adjust. 🤷 |
|
FWIW the s390x target also has a "soft-float" target feature and there we already mark "vector" as incompatible. ARM also has "soft-float" and there we don't mark anything. ARM also has much more explicit ABI control so maybe setting |
This comment has been minimized.
This comment has been minimized.
21a23e9 to
5594310
Compare
|
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. |
|
@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
|
Definitely happy to just say "no, you can't do that" for strange combinations. |
It might crash, but it does not always crash. I haven't found any documentation on the LLVM side about which target feature combinations they support and which they don't support.
The combination isn't that strange IMO -- you can use a soft-float ABI but still locally have the instruction & registers available. But LLVM just doesn't (always) support that. |
|
A real-world data point in support of this FCW, from a target you can't crater — and a failure mode that isn't SIGILL. I hit this on The crate is a Zero vector instructions. Every It did not crash. No SIGILL, no link error, no warning. The binary booted and produced correct output — the soft-float path preserves single-rounding semantics — it was just catastrophically slow. Measured against the same workload on the same machine (Dell Inspiron 15, i5-5200U, bare metal), rebuilding against a custom target spec with the float features removed took one hot function from 1.65–1.67 × 10⁹ ticks/token to 6.48–7.59 × 10⁶, a 217–258× recovery, and the resulting binary was ~50 KB smaller: We spent weeks attributing this to our own code. The only thing that found it was counting instructions in the shipped artifact; we now gate staging on a census that fails when So: strong +1 on warning rather than staying silent. The SIGILL cases at least announce themselves. This one ships. Scope-wise I can only speak to Full write-up and logs, if useful: https://github.com/Aefinity-AI/alice-aegis/blob/main/docs/posts/2026-08-05_uefi-soft-float-deletes-your-avx2.md |
|
Thanks for the feedback! (Note that under our just-adopted AI policy, we consider it improper to just copy-paste AI reports into PR/issue comments. Please use your own words and put the detailed AI report into a clearly indicated, separate section that one can easily skip.) |
Fixes #117938
Enabling both the avx2 and soft-float target features is not supported by LLVM and can crash the backend. Let's preempt that with rust-level checks. (I still think there's also an LLVM bug here, it shouldn't just SIGILL on unexpected target feature configurations, but that's a different discussion.)
What is not clear to me is whether this just affects just avx2 or also avx or even sse (we don't support mmx/3dnow separately). @dianqk do you know more about this? To be safe, let's reject "sse" and therefore by implication also all other x86 vector target features.
This PR turns
#[target_feature(enable = "sse")]on a softfloat target into an FCW similar to what we do on aarch64 (see #135160). The FCW only affects people building for soft-float targets which is a fairly small percentage of our overall users (and which means we cannot meaningfully crater this). I hence went for "report in deps" immediately so that the people building the actual binaries see these warnings that their upstreams probably will never see.