[llvm] [LangRef] Clarify specification for float min/max operations (PR #172012)

[Phoebe Wang via llvm-commits]

phoebewang wrote:

> I must say I personally do not fully understand the concern around signed zero handling. People who do not care about signed zero can easily set the flag and get exactly what they want. The only downside I see is with the import of legacy bitcode, but do people really have old hard-to-update IR files laying around with performance criticial min/max? I am very doubtful of that and to my knowledge LLVM IR was always intended as an evolving language.

This is one of my concern, but now I'm concerning more about the [optimization](https://discourse.llvm.org/t/rfc-a-consistent-set-of-semantics-for-the-floating-point-minimum-and-maximum-operations/89006/69), which looks to me the only motivation changing the signed zero semantics of `minnum/maxnum`. However, according to [the reply](https://discourse.llvm.org/t/rfc-a-consistent-set-of-semantics-for-the-floating-point-minimum-and-maximum-operations/89006/74), the cost of quieting sNaN needs to take into account, which makes me worry about the signed zero handling cost no been taken equally. And if the optimization is not general enough, it should be done in target specific code, then there's no requirement to change the signed zero semantics at all.


> Note that I think having a target-independent way to express exactly what IEEE 2008 + signed zero provide is necessary. Most hardware implement do exactly that (including x86 with VRANGE) and we even already have a builtin "__builtin_elementwise_minnum" which is officially released in Clang 21 and is documented to behave that way. Although I think it's currently broken, I don't think we slould walk that back the concept.

Isn't the best way to define `minnum_ieee/maxnum_ieee` for that and keep `minnum/maxnum` both sNaN and signed zero non-determinism?

https://github.com/llvm/llvm-project/pull/172012