x86: lowering of `llvm.minnum` and `llvm.maxnum` does not handle signed zeroes correctly

[valadaptive]

#112852 updated the documentation and semantics around the llvm.minnum and llvm.maxnum intrinsics. The langref for e.g. llvm.minnum now says (emphasis mine):

Follows the semantics of minNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes of this intrinsic.
[...]
If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C and IEEE-754-2008: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.

However, this is not respected for x86. It lowers these operations to a minps/minpd plus a cmpunord to handle NaN, but makes no effort to handle signed zeroes if the nsz attribute is absent.

You can see this behavior in this godbolt example. Note that the Rust min intrinsic is lowered to llvm.minnum (without any nsz attribute), which is then compiled into a minps+cmpunordps sequence.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: None (valadaptive)

https://github.com//pull/112852 updated the documentation and semantics around the `llvm.minnum` and `llvm.maxnum` intrinsics. The langref for e.g. `llvm.minnum` now says (emphasis mine):

> Follows the semantics of minNum in IEEE-754-2008, except that -0.0 < +0.0 for the purposes of this intrinsic.
[...]
> If the intrinsic is marked with the nsz attribute, then the effect is as in the definition in C and IEEE-754-2008: the result of minnum(-0.0, +0.0) may be either -0.0 or +0.0.

However, this is not respected for x86. It lowers these operations to a minps/minpd plus a cmpunord to handle NaN, but makes no effort to handle signed zeroes if the nsz attribute is absent.

You can see this behavior in this godbolt example. Note that the Rust min intrinsic is lowered to llvm.minnum (without any nsz attribute), which is then compiled into a minps+cmpunordps sequence.

[phoebewang]

That's why I'm reverting it, see #168838

[RalfJung]

This is a duplicate of #49230 I think?

[valadaptive]

I considered just leaving a comment in #49230, but that issue seems pretty inactive, and a lot of new developments (like #112852) occurred long after the last comment in that issue thread. My worry was that nobody would notice a comment there.

(EDIT: There's technically some difference here too; #49320 is about the semantics of the LLVM intrinsics not matching IEEE-754. This issue is about the x86 lowering not matching the semantics of the LLVM intrinsics.)