Deprecate MXCSR-related intrinsics

[GabrielMajeri]

Fixes #781.

[rust-highfive]

r? @gnzlbg

(rust_highfive has picked a reviewer for you, use r? to override)

[gnzlbg]

cc @rkruppe

Is reading the MXCSR ok ? If not, why is that UB ?

[hanna-kruppe]

As far as LLVM is concerned:

The default LLVM floating-point environment assumes that floating-point instructions do not have side effects. Results assume the round-to-nearest rounding mode. No floating-point exception state is maintained in this environment.

This doesn't contain the magic words "behavior is undefined" but if you believe that writing MXCSR is UB, then this wording indicates that reading it is also UB because the UB flows from the assumption that the LLVM IR instructions are side-effect free and both reading and writing FP exception state conflicts with that.

[gnzlbg]

This doesn't contain the magic words "behavior is undefined" but if you believe that writing MXCSR is UB, then this wording indicates that reading it is also UB because the UB flows from the assumption that the LLVM IR instructions are side-effect free and both reading and writing FP exception state conflicts with that.

What's the side-effect of reading the MXCSR register ?

[hanna-kruppe]

What's the side-effect of reading the MXCSR register ?

Reading doesn't have side effects AFAIK, but doing reads contradicts the assumption that floating point instructions don't have side effects (because they affect which value gets read from MXCSR).

[bors]

☔ The latest upstream changes (presumably 0716b22) made this pull request unmergeable. Please resolve the merge conflicts.

[GabrielMajeri]

I've rebased the PR, the build failures seem to be unrelated to the MXCSR changes.

[Amanieu]

The build failures should be fixed now, can you rebase again?

[GabrielMajeri]

@Amanieu I've fixed some of the tests, but there are still others which use _MM_GET_EXCEPTION_STATE/_MM_SET_EXCEPTION_STATE (for example, test_mm_comieq_ss_vs_ucomieq_ss). Should I just get rid of those tests as well, or allow them to use the deprecated functions (even though it's sort-of undefined behavior)?

[Amanieu]

I think it's fine to leave the tests as they are for now and just allow the warning.

[Amanieu]

With that said, there have been changes in LLVM since this PR was opened in 2019 and I am not sure if the original reasons for deprecating these functions still apply.

[GabrielMajeri]

@Amanieu Hmm, you're right, I'm not convinced using them is instantly undefined behavior anymore. I'm going to close this PR for now and leave a comment on the original issue, if someone's interested in further investigating the problem.