The run-pass/simd-intrinsic-float-minmax.rs fails on mips* with glibc 2.27

[draganmladjenovic]

This is a combination of several issues. First on Mips targets the LLVM expands @llvm.min/maxnum.v4f32 into per element fminf/fmaxf libcalls. Since glibc 2.25 [1] the semantics of these libm functions is changed and no longer follows the rules defined in LLVM lang ref [2]. Now these functions return QNAN if any of the input is SNAN. And finally the bit-pattern of libcore::f32::NAN constant is actually interpreted as SNAN by Mips hardware [3] [4] triggering the issue.

@gnzlbg
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=20947
[2] https://llvm.org/docs/LangRef.html#id480
[3] https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html
[4] https://dmz-portal.mips.com/wiki/MIPS_ABI_-_NaN_Interlinking#1._Introduction

[gnzlbg]

First on Mips targets the LLVM expands @llvm.min/maxnum.v4f32 into per element fminf/fmaxf libcalls.

Is this actually correct? This appears to be an llvm bug to me. cc @rkruppe

[hanna-kruppe]

Great timing. Just this week it was brough up on llvm-dev that LLVM apparently doesn't even have consistent semantics for these intrinsics, and it's not even clear which semantics should be used (don't miss Steve Canon's reply).

[gnzlbg]

@rkruppe from chatting on IRC I think it was always clear, albeit undocumented, that llvm minnum/maxnum were supposed to follow IEEE2018.

IIUC glibc was implementing IEEE2008 incorrectly, which accidentaly made it implement IEEE2018 properly?. Now that glibc is sticking to IEEE2008, LLVM shouldn't probably call those libm functions anymore.

Also, is f32::NAN a QNAN or an SNAN ? Or is that platform dependent? (the docs don't say)

[hanna-kruppe]

from chatting on IRC I think it was always clear, albeit undocumented, that llvm minnum/maxnum were supposed to follow IEEE2018.

Maybe that was someone's intent but evidently the language reference explicitly contradicts this, and the lowering to fmin/fmax is incompatible with this interpretation too. So nothing is clear really, it's a huge mess that will have to be disentangled with uncertain results.

Also, is f32::NAN a QNAN or an SNAN ? Or is that platform dependent? (the docs don't say)

We're not very precise about distinguishing sNaN and qNaN in the language and standard library. I don't think we should be, either, since LLVM doesn't always preserve signaling-ness. If interrogated back when the constant was added, people probably would have said it should be qNaN because sNaN is "scary", but that doesn't mean much.

[gnzlbg]

@draganmladjenovic as a way to "fix" the test so that it doesn't block work on mips, we should probably just use a QNAN there instead of f32::NAN on MIPS only at least for the time being, and pointing to this issue.

[draganmladjenovic]

@gnzlbg Ok, will send the PR.

[steveklabnik]

Triage: I am not sure of the best way to reproduce this issue, as I don't have the needed hardware.