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.

Which differences are acceptable?

• I assume that we only want to tolerate differences in NaN payloads/signs, but not in whether a NaN is returned. (That was relevant for instance in Revert "Merge pull request #1871 from folkertdev/aarch64-float-min-max" #2052.)
• 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. I don't know if we currently use LLVM's portable SIMD representation here.

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. Would the module-level docs 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".