Decide and document where stdarch intrinsics are allowed to diverge from asm behavior

[RalfJung]

stdarch has started using the simd_* LLVM intrinsics for many operations, which is great news for backends like cranelift and Miri. However, it also means we get extra optimizations that would otherwise not apply: LLVM will constant-fold these operations using its usual NaN rules, which means that the sign and payload of a NaN can be different from what would happen if the vendor intrinsic was implemented by an inline assembly block. Furthermore, SNaNs can be non-deterministically treated like QNaNs, which can make a difference for operations where QNaN input lead to non-NaN results.

Which differences are acceptable?

• I assume we definitely want to tolerate differences in NaN payloads/signs. Without that, we couldn't use any portable SIMD operations in stdarch. Arguably, this is already covered by the existing general float NaN docs, though not everyone might expect that to apply even to vendor intrinsics.
• What about differences in whether a NaN is returned? This is relevant e.g. for some variants of min/max where the vendor may say that an SNaN input always produces a NaN result, but the portable LLVM intrinsic makes no such guarantee and could produce a non-NaN result. See Revert "Merge pull request #1871 from folkertdev/aarch64-float-min-max" stdarch#2052 for a concrete example where such SNaN behavior was fixed.
• On targets like ARM32 where subnormal numbers do not work properly for SIMD vectors, we might also see differences in the actual numerical results -- if LLVM constant-folds those operations, that will be done with proper subnormal support. In fact, LLVM itself mistreats those operations on ARM32, leading to miscompilations (32-bit ARM NEON intrinsics are unsound due to subnormal flushing #129880).

Currently, I don't think we properly document this anywhere? It doesn't seem too unlikely that someone might expect the vendor intrinsics to always behave exactly like the corresponding asm instructions, so we better clarify the expectations here. Once a decision has been made, the module-level docs might be a good place to document this.
Cc @rust-lang/libs-api

[RalfJung]

@nikic wrote

For example, are you suggesting that we can't have target intrinsics lowering to simd_fmul or simd_fadd, because these have different sNaN semantics for 1.0 and -0.0 operands? I don't think we want to go there.

Can you explain what the SNaN semantics issue is that you are alluding to here? I am not aware of this issue.

EDIT: Oh, you mean the fact that the NaN might not be quieted? I think that's fine, that's "just" changing which NaN is returned. but we shouldn't change whether a NaN is returned.

[RalfJung]

@Amanieu @folkertdev @sayantn -- seems like there's not actually consensus on what the rules should be here, so we need to have a discussion before documenting anything. :)

Specifically, @nikic is proposing to also apply the principle that SNaN inputs can be treated like QNaN. More formally, I think this means that before the operation is executed, for any SNaN-input, we can non-deterministically turn it into a QNaN and then use that as the actual input to the operation. (TODO: figure out the exact set of QNaNs this may choose from.)
LLVM documents this as a general principle. Rust does not. This rule only makes a difference for the few operations where NaN inputs can lead to non-NaN results, and even more specifically where whether or not the input NaN is signaling influences whether the result is non-NaN. We instead just document this property for each of them individually. To my knowledge, the only such operations are pow, powi, maxnum, minnum. (In particular, minimum and minimumnum and their max* variants are not affected, and Rust does not expose maxnum/minnum, so we only have to document this for pow*.)

I am hesitant to apply this principle here since whether or not the result is a NaN is very visible, and people using the vendor intrinsics should get the actual vendor-defined behavior.

[nikic]

@nikic wrote

For example, are you suggesting that we can't have target intrinsics lowering to simd_fmul or simd_fadd, because these have different sNaN semantics for 1.0 and -0.0 operands? I don't think we want to go there.

Can you explain what the SNaN semantics issue is that you are alluding to here? I am not aware of this issue.

EDIT: Oh, you mean the fact that the NaN might not be quieted? I think that's fine, that's "just" changing which NaN is returned. but we shouldn't change whether a NaN is returned.

Yes, that's what I'm referring to. But I don't think this is "just", as long as there are operations that (can) have different behavior for sNaN inputs. This is different from a pure payload change that can only be observed by transmutes.

Even if you have a minnum_ieee operation that has strict IEEE 754-2008 sNaN semantics, then minnum_ieee(sNaN * 1.0, x) gets you back the non-determinism. This is why I'm saying it does not make sense to follow sNaN semantics only in some places. You either fully support it, or you don't. The premise behind our current sNaN semantics is that practically speaking, nobody actually cares about sNaN -- the only thing that's important is that the semantics are coherent in the sense that we don't get miscompilations through contradictory assumptions.

[RalfJung]

The sign of a NaN leaks via is_sign_positive - IMO this is largely equivalent to the concern you mention where the SNaN-ness of a NaN can "leak" via pow or minNum. So I think there already is no truly coherent story for why all this nondeterminism is "okay".

[RalfJung]

We should probably nominate this for libs-api discussion... I guess that means we need an issue in the main repo as they won't scan this repo for nominated issues? The label doesn't even exist here.^^

I'll move this over to the main repo.

[Amanieu]

The general rule we've been using for the stdarch intrinsics is that we want to follow what Clang does. Looking at Clang, this is what is currently happening (I only checked ARM for this):

• Simple operations like float-multiply are lowered to an LLVM fmul instruction. LLVM will perform constant-folding on these assuming normal IEEE semantics.
• More tricky operations like min/max are lowered to target-specific intrinsics like llvm.arm.neon.vmaxnm.v2f32. LLVM will not touch these and lower them to the corresponding instruction directly.

This means that, regarding your 3 points, the current Clang behavior here is:

• NaN payload differences are tolerated.
• SNaN is treated specially when passed as an input to an operation that is sensitive to the difference between SNaN and QNaN.
• Subnormal numbers are treated inconsistently on ARM32 depending on whether they are const-evaluated or used by instructions at runtime. However I would argue that this is really an LLVM bug and not the correct behavior. Ideally all of the ARM32 floating-point stdarch intrinsics should lower directly to the underlying instruction and not to generic SIMD.

[RalfJung]

However I would argue that this is really an LLVM bug and not the correct behavior. Ideally all of the ARM32 floating-point stdarch intrinsics should lower directly to the underlying instruction and not to generic SIMD.

As far as I can tell, stdarch is using simd_* here, i.e., we are generating LLVM fadd which has IEEE semantics, not arch-specific ones like llvm.arm.neon.*. So how is this an LLVM bug if we then get IEEE semantics? The miscompilations are obviously an LLVM bug, but if we want guaranteed subnormal flushing, we shouldn't use LLVM's fadd.

[RalfJung]

More tricky operations like min/max are lowered to target-specific intrinsics like llvm.arm.neon.vmaxnm.v2f32. LLVM will not touch these and lower them to the corresponding instruction directly.

That makes me wonder what clang does on s390x. There, we can't use the llvm.s390 operation because we need a transparent fallback when the instruction is not available -- at least, that seems to be the precedent from C, odd as that may seem for a vendor intrinsic. See rust-lang/stdarch#2060 for context.

[Amanieu]

As far as I can tell, stdarch is using simd_* here, i.e., we are generating LLVM fadd which has IEEE semantics, not arch-specific ones like llvm.arm.neon.*. So how is this an LLVM bug if we then get IEEE semantics? The miscompilations are obviously an LLVM bug, but if we want guaranteed subnormal flushing, we shouldn't use LLVM's fadd.

I'm just saying that Clang has the same buggy behavior, and we are just doing the same as Clang here.

[mohammedsalman06112-blip]

Thanks for taking time and reporting this

…

On Wed, Mar 18, 2026, 3:26 AM Amanieu ***@***.***> wrote: *Amanieu* left a comment (rust-lang/rust#153990) <#153990 (comment)> As far as I can tell, stdarch is using simd_* here, i.e., we are generating LLVM fadd which has IEEE semantics, not arch-specific ones like llvm.arm.neon.*. So how is this an LLVM bug if we then get IEEE semantics? The miscompilations are obviously an LLVM bug, but if we want *guaranteed* subnormal flushing, we shouldn't use LLVM's fadd. I'm just saying that Clang has the same buggy behavior, and we are just doing the same as Clang here. — Reply to this email directly, view it on GitHub <#153990 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CABGL7HXYBYFSVKWDR4T7NL4RJMUXAVCNFSM6AAAAACWUK67TSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAOBQGYYTQMZRGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>