[llvm] [VPlan] Introduce CSE pass (PR #151872)

[Florian Hahn via llvm-commits]

================
@@ -122,6 +122,49 @@ void VPDef::dump() const {
 }
 #endif
 
+bool VPValue::isIdenticalTo(const VPValue *Other) const {
+  if (getVPValueID() != Other->getVPValueID() ||
+      hasDefiningRecipe() != Other->hasDefiningRecipe() ||
+      !getUnderlyingValue() != !Other->getUnderlyingValue())
+    return false;
+
+  auto *I = dyn_cast_or_null<Instruction>(getUnderlyingValue());
+  auto *OtherI = dyn_cast_or_null<Instruction>(Other->getUnderlyingValue());
+  if (I && OtherI)
+    return I->isIdenticalTo(OtherI);
+
+  if (hasDefiningRecipe()) {
+    // Special case for matching flags on instruction.
+    auto *VPI = dyn_cast<VPInstruction>(this);
+    auto *OtherVPI = dyn_cast<VPInstruction>(Other);
+    if (VPI && OtherVPI && VPI->hashFlags() != OtherVPI->hashFlags())
+      return false;
+
+    const VPRecipeBase *DefL = getDefiningRecipe();
+    const VPRecipeBase *DefR = Other->getDefiningRecipe();
+    return vputils::getOpcode(*DefL) == vputils::getOpcode(*DefR) &&
+           equal(DefL->operands(), DefR->operands());
----------------
fhahn wrote:

Just looking at the opcode + operands may not be correct, e.g. a VPWidenRecipe and a single-scalar VPRepcliateRecipe with same operand + opcode. We cannot replace the VPWidenRecipe with the single-scalar one. Replacing the other way around may work, but has cost implications (the introduced extract can be very costly)


Or a cast recipe. They can have the same opcode + operands, but different target-types.

For now, probably best to restrict to matching recipe ID as well and matching result types.

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