[llvm] Revert "LangRef: Clarify llvm.minnum and llvm.maxnum about sNaN and signed zero (#112852)" (PR #138451)

[Phoebe Wang via llvm-commits]

phoebewang wrote:

> I am a hard no this. We've never been in a consistent state on this and this makes negative progress towards getting into a sensible state. Reverting the langref doesn't address any of the open bugs.
> 
> TLDR:
> 
> 1. Most code introducing minnum / maxnum should really be emitting minimumnum/maximumnum. Just find and replacing all of these probably addresses most of the open issues. This was the effective behavior on some, but not all targets
> 2. All code referring to "fmin" or "fmax" should stop doing so and use one of the IEEE derived names. These only cause confusion.
> 3. CodeGen is still a mixed bag of inconsistency, the current langref establishes the trajectory

Sorry, I don't agree. We are not just reverting the langref for bugs. The inconsistent state is exactly the reason we need to revert it. Can you describe what a sensible state would be? I don't see a consensus about it. Without that, we don't even know what is the right direction.

My point is minnum / maxnum is one of floating-point math operations, applied to the general rules of `allowed to treat all NaNs as if they were quiet NaNs` as documented in [Behavior of Floating-Point NaN values](https://llvm.org/docs/LangRef.html#id2028). It also points to the solution that uses the [Constrained Floating-Point Intrinsics](https://llvm.org/docs/LangRef.html#constrainedfp). So defining a constrained minnum / maxnum intrinsics is the right direction from my point of view. The inconsistency of signaling nan is an inherent characteristic in default FP mode. It cannot be solved by just a change of langref on one or two intrinsics.

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