[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