[PATCH] D159202: [VPlan] Simplify redundant trunc (zext A) pairs to A.

[Ayal Zaks via Phabricator via llvm-commits]

Ayal added inline comments.


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp:821
 
+/// Return the scalar size in bits for \p VPV if possible.
+static unsigned getSizeInBits(VPValue *VPV) {
----------------
rename getTypeSizeInBits()?

Worth introducing getType(), possibly as a method of VPValue?

Callers could then get its scalar size in bits if interested, although in this case the types themselves should arguably be compared rather than their scalar sizes in bits?


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp:826
+    return UV->getType()->getScalarSizeInBits();
+  if (auto *VPC = dyn_cast<VPWidenCastRecipe>(VPV)) {
+    return VPC->getResultType()->getScalarSizeInBits();
----------------
Should this cast case be placed first?


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp:829
+  }
+  llvm_unreachable("trying to get type of a VPValue without type info");
+}
----------------
(hence getType() may be more natural.)


================
Comment at: llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp:846-852
+    VPValue *A = R.getOperand(0);
+    VPRecipeBase *ADef = A->getDefiningRecipe();
+    // Simplify (trunc (zext A) to Ty) -> A if Ty is equal to the type of A.
+    if (ADef && getOpcodeForRecipe(*ADef) == Instruction::ZExt &&
+        getSizeInBits(R.getVPSingleValue()) ==
+            getSizeInBits(ADef->getOperand(0)))
+      return R.getVPSingleValue()->replaceAllUsesWith(ADef->getOperand(0));
----------------
("if Ty is equal to the type of A" also refers to types rather than their scalar size in bits.)


================
Comment at: llvm/test/Transforms/LoopVectorize/if-pred-stores.ll:542
   %tmp4 = zext i8 %tmp3 to i32
   %tmp5 = trunc i32 %tmp4 to i8
   store i8 %tmp5, ptr %tmp2, align 1
----------------
This "removeRedundantCasts" elimination seems to catch opportunities in the original (unoptimized) code rather than opportunities generated by LV itself, as in Mul-by-1/Add-0. But that may change once bitwidth minimization takes place as VPlan2VPlan transform (D149903)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D159202/new/

https://reviews.llvm.org/D159202