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

[Matt Arsenault via llvm-commits]

arsenm wrote:

> I do see your point. Another alternative, which is more consistent with LLVM's overall treatment of sNaN and also your "nobody actually cares about sNaN" perspective, is to specify that minnum/maxnum with an sNaN argument may non-deterministically convert it to a qNaN. This means we are allowed to lower minnum/maxnum to operations that either follow or don't follow the IEEE-754-2008 sNaN behavior. This would effectively specify the current backend behavior.
> 

That's my interpretation of what the (unclear) OpenCL spec rule (but not what the conformance test presently implements).

One issue with fuzzing out the intrinsic like this is you now can't reliably implement minimumnum/maximumnum on top of minnum/maxnum. That's critical in the codegen versions of the intrinsics, but I could imagine wanting to perform the expansion in the IR for optimization. e.g. we could avoid canonicalizes somewhere important like in a loop by inserting explicit canonicalize at the unanalyzable source, and replacing the loop op with minnum 

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