From dfcbf78a841c630caf21c0b767008d5444c28c80 Mon Sep 17 00:00:00 2001 From: Florian Hahn Date: Tue, 7 Oct 2025 12:40:47 +0100 Subject: [PATCH 1/2] [VPlan] Assign custom opcodes to recipes not mapping to IR opcodes. We can perform CSE on recipes that do not directly map to Instruction opcodes. One example is VPVectorPointerRecipe. Currently this is handled by supporting them in ::canHandle, but currently that means that we return std::nullopt from getOpcodeOrIntrinsicID() for it. This currently only works, because the only case we return std::nullopt and perform CSE is VPVectorPointerRecipe. But that does not work if we support more such recipes, like VPPredInstPHIRecipe (https://github.com/llvm/llvm-project/pull/162110). To fix this, return a custom opcode from getOpcodeOrIntrinsicID for recipes like VPVectorPointerRecipe, using the VPDefID after all regular instruction opcodes. --- llvm/lib/Transforms/Vectorize/VPlan.h | 1 + .../lib/Transforms/Vectorize/VPlanTransforms.cpp | 16 +++++++++++----- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/llvm/lib/Transforms/Vectorize/VPlan.h b/llvm/lib/Transforms/Vectorize/VPlan.h index c167dd7f65fac..98fd7c9273c5d 100644 --- a/llvm/lib/Transforms/Vectorize/VPlan.h +++ b/llvm/lib/Transforms/Vectorize/VPlan.h @@ -1064,6 +1064,7 @@ class LLVM_ABI_FOR_TEST VPInstruction : public VPRecipeWithIRFlags, ResumeForEpilogue, /// Returns the value for vscale. VScale, + OpsEnd = VScale, }; /// Returns true if this VPInstruction generates scalar values for all lanes. diff --git a/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp b/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp index ebf833e2b7e88..cb900c03a4bdc 100644 --- a/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp +++ b/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp @@ -1982,6 +1982,13 @@ struct VPCSEDenseMapInfo : public DenseMapInfo { .Case([](auto *I) { return std::make_pair(true, I->getVectorIntrinsicID()); }) + .Case([](auto *I) { + // For recipes that do not directly map to LLVM IR instructions, + // assign opcodes after the last VPInstruction opcode (which is also + // after the last IR Instruction opcode), based on the VPDefID. + return std::make_pair(false, + VPInstruction::OpsEnd + 1 + I->getVPDefID()); + }) .Default([](auto *) { return std::nullopt; }); } @@ -2005,12 +2012,9 @@ struct VPCSEDenseMapInfo : public DenseMapInfo { static bool canHandle(const VPSingleDefRecipe *Def) { // We can extend the list of handled recipes in the future, // provided we account for the data embedded in them while checking for - // equality or hashing. We assign VPVectorEndPointerRecipe the GEP opcode, - // as it is essentially a GEP with different semantics. - auto C = isa(Def) - ? std::make_pair(false, Instruction::GetElementPtr) - : getOpcodeOrIntrinsicID(Def); + // equality or hashing. + auto C = getOpcodeOrIntrinsicID(Def); // The issue with (Insert|Extract)Value is that the index of the // insert/extract is not a proper operand in LLVM IR, and hence also not in // VPlan. @@ -2048,6 +2052,8 @@ struct VPCSEDenseMapInfo : public DenseMapInfo { vputils::isSingleScalar(L) != vputils::isSingleScalar(R) || !equal(L->operands(), R->operands())) return false; + assert(getOpcodeOrIntrinsicID(L) && getOpcodeOrIntrinsicID(R) && + "must have valid opcode info for both recipes"); if (auto *LFlags = dyn_cast(L)) if (LFlags->hasPredicate() && LFlags->getPredicate() != From 1a28ac3bee84c9226135fc64df9c591bcff0b1d1 Mon Sep 17 00:00:00 2001 From: Florian Hahn Date: Wed, 8 Oct 2025 18:21:12 +0100 Subject: [PATCH 2/2] !fixup adjust whitespace --- llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp b/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp index f811d097117e9..8d0870b69121f 100644 --- a/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp +++ b/llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp @@ -2013,8 +2013,8 @@ struct VPCSEDenseMapInfo : public DenseMapInfo { // We can extend the list of handled recipes in the future, // provided we account for the data embedded in them while checking for // equality or hashing. - auto C = getOpcodeOrIntrinsicID(Def); + // The issue with (Insert|Extract)Value is that the index of the // insert/extract is not a proper operand in LLVM IR, and hence also not in // VPlan.