[llvm] [VPlan] Support live-ins without underlying IR in type analysis. (PR #80723)

via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 20 13:39:47 PST 2024


================
@@ -203,6 +198,16 @@ Type *VPTypeAnalysis::inferScalarTypeForRecipe(const VPReplicateRecipe *R) {
   llvm_unreachable("Unhandled opcode");
 }
 
+VPTypeAnalysis::VPTypeAnalysis(VPlan &Plan, LLVMContext &Ctx) : Ctx(Ctx) {
+  auto *CanIV = Plan.getCanonicalIV();
+  Type *CanIVTy = inferScalarType(CanIV);
+  CachedTypes[&Plan.getVectorTripCount()] = CanIVTy;
+  CachedTypes[&Plan.getVFxUF()] = CanIVTy;
+  CachedTypes[Plan.getTripCount()] = CanIVTy;
+  if (auto *BTC = Plan.getBackedgeTakenCount())
+    CachedTypes[BTC] = CanIVTy;
----------------
ayalz wrote:

These live-ins-w/o-an-underlying-value VPValues are temporary place-holders that should be replaced by recipes, as the boundary of VPlan's scope expands; or folded into constants (UF, times non-scalable VF). So fixing their type for now seems ok. Still, it may be better to pass and record the "Canonical Type" of (the start value - a zero that may be replaced - of) the Canonical IV directly, rather than call the recursive inferScalarType() during construction of VPTypeAnalsis.
`VPTypeAnalysis::VPTypeAnalysis(Type *CanTy, LLVMContext &Ctx) : CanTy(CanTy), Ctx(Ctx) {}`
Perhaps (also) record it in VPlan, as part of addCanonicalIVRecipes(); or at-least have VPlan provide a method to retrieve it.
Plus, have these VPValues lookup this type when needed, rather than listing them all here upfront, and maintaining this list as it changes?
(BTW, is Ctx needed?)
(Another option may be to record their type upon construction, using another subclass of VPValue, is better avoided being place-holders.)

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


More information about the llvm-commits mailing list