[llvm] [VPlan] Introduce VPInstructionWithType, use instead of VPScalarCast(NFC) (PR #129706)
via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 9 14:50:08 PDT 2025
================
@@ -1023,6 +1022,56 @@ class VPInstruction : public VPRecipeWithIRFlags,
/// Returns the symbolic name assigned to the VPInstruction.
StringRef getName() const { return Name; }
+
+ /// Return true if \p U is a cast.
+ static bool isCast(const VPUser *U) {
+ auto *VPI = dyn_cast<VPInstruction>(U);
+ return VPI && Instruction::isCast(VPI->getOpcode());
+ }
+};
+
+/// A specialization of VPInstruction augmenting it with a dedicated result
+/// type, to be used when the opcode and operands of the VPInstruction don't
+/// directly determine the result type.
+class VPInstructionWithType : public VPInstruction {
+ /// Scalar result type produced by the recipe.
+ Type *ResultTy;
+
+public:
+ VPInstructionWithType(unsigned Opcode, ArrayRef<VPValue *> Operands,
+ Type *ResultTy, DebugLoc DL, const Twine &Name = "")
----------------
ayalz wrote:
Worth documenting somewhere that VPInstructionWithType does not have its own VPDef::VPInstructionWithTypeSC identifying it, as do all other recipes, but it uses VPInstructionSC instead. VPInstructions should be identified according to their opcode, whether they are actually of class VPInstruction itself or a subclass thereof.
I.e., there is no `VP_CLASSOF_IMPL(VPDef::VPInstructionWithTypeSC)` here.
https://github.com/llvm/llvm-project/pull/129706
More information about the llvm-commits
mailing list