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

[Phoebe Wang via llvm-commits]

phoebewang wrote:

> There's no "right" or "wrong", just trade-offs. And the trade-offs will be much more clear once actual patches get written, which currently is blocked on having a coherent documented semantics to review the patches against.

An acceptable approach probably full of trade-offs, but candidates can be judged by right or wrong. Patches are nice to have, but there are ways to prejudge, e.g., logical reasoning.

The reason of changing LangRef and follow up implementations is a proposed optimization (no details given so far) *MUST* use minnum/maxnum with changed semantics. It's no much difficult to prove it's wrong with known conditions and some assumptions according to my understanding.

### Assumptions

The optimization transforms none minnum/maxnum instructions to minnum/maxnum. (This might be wrong, but I can't think out any benefit if just transforming `nsz minnum/maxnum` to minnum/maxnum.)

### Reasoning

1. maximumnum/minimumnum cannot be used for the optimization, because they must respect sNaNs, hence have cost on some targets;
2. This patch changed sNaNs non-determinism for the minnum/maxnum, because any LLVM instructions are sNaNs determinism including maximumnum/minimumnum, unless it's documented explictly like minnum/maxnum;

### Conflicts

- If R2 is true, the optimization cannot transform any instructions except for minnum/maxnum, which conflicts with the assumption;
- If R2 is false, R1 is false too;

Then we get the conclusion the use and only use of minnum/maxnum in the optimization is just wrong.

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