[llvm] [LV] Vectorize FMax via OrderedFCmpSelect w/o fast-math flags. (PR #146711)

[via llvm-commits]

================
@@ -47,6 +47,9 @@ enum class RecurKind {
   FMul,     ///< Product of floats.
   FMin,     ///< FP min implemented in terms of select(cmp()).
   FMax,     ///< FP max implemented in terms of select(cmp()).
+  OrderedFCmpSelect, ///< FP max implemented in terms of select(cmp()), but
+                     /// without any fast-math flags. Users need to handle NaNs
+                     /// and signed zeros when generating code.
----------------
ayalz wrote:

Continuing to look for good name(s), how about:
```suggestion
  FMaxOGT, ///< FP max implemented in terms of select(cmp(OGT)), being
           /// strict with signed zeroes and NaN's, without fast-math flags.
  FMinOLT, ///< FP min implemented in terms of select(cmp(OLT)), being
           /// strict with signed zeroes and NaN's, without fast-math flags.

```
Have distinct cases for max vs. min, as in other cases, or fuse them into one FMinMax?

Rename existing FMax/FMin to FMaxFast/FMinFast?

NaN's are handled the same by OrderedFCmpSelect and by FMax/FMin-with-OGT/OLT as their compare predicate, where the latter assume all elements are non-NaN by FMF; the distinction lies in tie breaking +0/-0?

Need to also indicate if +0/-0 ties are broken according to the sign of the first zero or of last zero, which can be solved by computing index of first max/min or index of last max/min, respectively. Cases FMaxOGE/FMinOLE can be added later to denote +0/-0 ties are broken by last index rather than first index.

("Users need to handle ..." also applies to FMaxNum/FMinNum, suffice for enum to state semantics rather than how to keep them, there and here.)

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