[llvm] [RISCV][VLOpt] Consolidate EMUL=SEW/EEW*LMUL logic [NFC] (PR #122021)

[Philip Reames via llvm-commits]

================
@@ -721,16 +708,48 @@ static OperandInfo getOperandInfo(const MachineOperand &MO,
   case RISCV::VREDOR_VS:
   case RISCV::VREDSUM_VS:
   case RISCV::VREDXOR_VS: {
-    if (MO.getOperandNo() == 2)
-      return OperandInfo(MIVLMul, MILog2SEW);
-    return OperandInfo(MILog2SEW);
+    return MILog2SEW;
   }
 
   default:
     return {};
   }
 }
 
+static OperandInfo getOperandInfo(const MachineOperand &MO,
+                                  const MachineRegisterInfo *MRI) {
+  const MachineInstr &MI = *MO.getParent();
+  const RISCVVPseudosTable::PseudoInfo *RVV =
+      RISCVVPseudosTable::getPseudoInfo(MI.getOpcode());
+  assert(RVV && "Could not find MI in PseudoTable");
+
+  std::optional<unsigned> Log2EEW = getOperandLog2EEW(MO, MRI);
+  if (!Log2EEW)
+    return {};
+
+  switch (RVV->BaseInstr) {
+  // Vector Reduction Operations
+  // Vector Single-Width Integer Reduction Instructions
+  // The Dest and VS1 only read element 0 of the vector register. Return just
+  // the EEW for these.
+  case RISCV::VREDAND_VS:
+  case RISCV::VREDMAX_VS:
+  case RISCV::VREDMAXU_VS:
+  case RISCV::VREDMIN_VS:
+  case RISCV::VREDMINU_VS:
+  case RISCV::VREDOR_VS:
+  case RISCV::VREDSUM_VS:
+  case RISCV::VREDXOR_VS:
----------------
preames wrote:

(Recording this just for future reference, no action needed.)

Hm, the more I think about this, the more I'm wondering if the existing code is correct.  This codepath causes us to ignore the EMUL entirely when checking whether a user is compatible with a def.  I'm not sure that's right.

The bit I'm worried about is not the result of the reduction (i.e. the single element), it's the passthru operand.  If the instruction is TU, we have to preserve the tail elements through the reduction.  If the reduction vector source is also equal to the passthru, we can end up with a situation where reducing VL changes the tail elements of the definition and that's visible through the reduction.

Ah, but we're okay.  We'd reject the use which was the reduction pass thru entirely.  So as a result, we only reduce the VL of def if it *can't* reach the passthru operand.  

I think you are right that all "scalar in vector" arguments probably should have consistent handling, but I think the current code is merely conservative, not incorrect for these.  

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