[llvm] [LV] Vectorize fmin/fmax reductions (PR #198300)

[Nashe Mncube via llvm-commits]

================
@@ -1680,6 +1682,20 @@ bool VPlanTransforms::handleMaxMinNumReductions(VPlan &Plan) {
   if (MinOrMaxNumReductionsToHandle.empty())
     return true;
 
+  // Unsupported VP reduction Phis should be handled by handleMultiUseReductions
+  // if the unsupported phi is part of a FindIV chain which qualifies,
+  // regardless if it's a min/max or minnum/maxnum reduction op.
+  bool AllUnsupportedPhisInMultiUseChain =
+      all_of(UnsupportedVPRdxPhis, [&](VPReductionPHIRecipe *R) {
+        return R->hasOneUse() && all_of(R->users(), [](VPUser *U) {
+                 CmpPredicate Pred;
+                 return match(U, m_Select(m_Cmp(Pred, m_VPValue(), m_VPValue()),
+                                          m_VPValue(), m_VPValue()));
+               });
+      });
+  if (!UnsupportedVPRdxPhis.empty() && AllUnsupportedPhisInMultiUseChain)
+    return true;
----------------
nasherm wrote:

Thanks for letting me know Florian, I had a dig through the langref to try and understand better.

@john-brawn-arm the langref seems to indicate that failure to vectorize `minnum/maxnum` reductions is expected due to the semantics of `minnum/maxnum` and it's handling of sNaNs 

https://llvm.org/docs/LangRef.html#llvm-minnum-intrinsic

Would you expect the difference in semantics not to make a difference in whether these vectorize? Correct me if I'm wrong but it seems like the failure to vectorize the reductions in the test cases you mentioned would have to be done in the patch adding support for the parallel def-use reductions. So _this_ current patch is really just be adding support for fmin/fmax reductions which have the simpler semantics of `maximumnum/minimumnum`


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