[llvm] [SLP] Fix canConvertToFMA operand selection and fmul costing (PR #216425)

[Alexey Bataev via llvm-commits]

================
@@ -14382,18 +14382,47 @@ static InstructionCost canConvertToFMA(ArrayRef<Value *> VL,
   InstructionsCompatibilityAnalysis Analysis(DT, DL, TTI, TLI);
   SmallVector<BoUpSLP::ValueList> Operands = Analysis.buildOperands(S, VL);
 
-  InstructionsState OpS = getSameOpcode(Operands.front(), TLI);
-  if (!OpS.valid())
-    return InstructionCost::getInvalid();
-
-  if (OpS.isAltShuffle() || OpS.getOpcode() != Instruction::FMul)
-    return InstructionCost::getInvalid();
-  if (!CheckForContractable(Operands.front()))
+  // The fmul may sit on either side of the add/sub. Look past operand 0 only
+  // for chains that do not allow reassociation. The gate is profitability, not
+  // correctness. A reassociative chain can be vectorized into a vector fmul
+  // feeding a reduction, which is usually better than the scalar fma chain
+  // this check protects. An fsub can only fold an fmul on its left, so stop at
+  // operand 0 there as well.
+  bool AllowReassoc =
+      any_of(VL, [](Value *V) { return match(V, m_AllowReassoc(m_Value())); });
+  bool OnlyFirstOperand = AllowReassoc || S.getOpcode() == Instruction::FSub;
----------------
alexey-bataev wrote:

```suggestion
  bool AllowReassoc =
      all_of(VL, [](Value *V) { return match(V, m_AllowReassoc(m_Value())); });
  bool OnlyFirstOperand = !AllowReassoc || S.getOpcode() == Instruction::FSub;
```
???

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