[llvm] LangRef: Clarify llvm.minnum and llvm.maxnum about sNaN (PR #112852)

[YunQiang Su via llvm-commits]

wzssyqa wrote:

> I'm not convinced this change is a good idea, as opposed to fixing the backends that implement it differently. LLVM has a general principle that sNaNs are treated more or less equivalent to qNaN, and this is the main case where sNaN inputs do very different things from qNaN inputs. The original text is pretty explicit that targets are supposed to use `llvm.canonicalize` to handle sNaN quieting if they're mapping to hardware that does distinguish between sNaN/qNaN, and I don't see any justification in this PR yet for why doing that is problematic.

Yes. We should fix the backends, while before we fix them, we need a standard that what extractly to do.
Since in lots of cases that llvm.minnum will fallback to libc call, so that, aligning with the behavior of fmin(3) is the most reasonable
way.

For `sNaNs are treated more or less equivalent to qNaN`, it was reasonable before we have IEEE754-2019 and C23.
While C23 clarifies fmin(3)/fmax(3), and IEEE754-2019/C23 introduced minimumNumber.
It is time to do some clarification for fmin(3).
I don't think that it is a good idea to have some suprise to users with code like:
```
float f(float a, float b) {
   return fminf(a, b);
}
```
As users may read manual from libc, where states that fmax(N, sNaN) => NaN, while we (llvm) produces N.

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