[llvm] [VPlan] Populate and use VPIRMetadata from VPInstructions (NFC) (PR #167253)

[David Sherwood via llvm-commits]

================
@@ -1495,31 +1499,26 @@ class VPWidenCastRecipe : public VPRecipeWithIRFlags, public VPIRMetadata {
 
 public:
   VPWidenCastRecipe(Instruction::CastOps Opcode, VPValue *Op, Type *ResultTy,
-                    CastInst &UI)
-      : VPRecipeWithIRFlags(VPDef::VPWidenCastSC, Op, UI), VPIRMetadata(UI),
-        Opcode(Opcode), ResultTy(ResultTy) {
-    assert(UI.getOpcode() == Opcode &&
-           "opcode of underlying cast doesn't match");
-  }
-
-  VPWidenCastRecipe(Instruction::CastOps Opcode, VPValue *Op, Type *ResultTy,
-                    const VPIRFlags &Flags = {},
+                    CastInst *UI = nullptr, const VPIRFlags &Flags = {},
                     const VPIRMetadata &Metadata = {},
                     DebugLoc DL = DebugLoc::getUnknown())
-      : VPRecipeWithIRFlags(VPDef::VPWidenCastSC, Op, Flags, DL),
+      : VPRecipeWithIRFlags(VPDef::VPWidenCastSC, Op,
+                            UI ? VPIRFlags(*UI) : Flags,
----------------
david-arm wrote:

I think this sort of thing could lead to confusion. It's not obvious to the caller that `Flags` is completely ignored if `UI` is non-null. I think it would be better to have different explicit constructors for different scenarios, i.e.

```
  VPWidenCastRecipe(Instruction::CastOps Opcode, VPValue *Op, Type *ResultTy,
                    CastInst &UI, const VPIRMetadata &Metadata = {}) { ... }

  VPWidenCastRecipe(Instruction::CastOps Opcode, VPValue *Op, Type *ResultTy,
                    const VPIRFlags &Flags = {}, DebugLoc DL = DebugLoc::getUnknown(), const VPIRMetadata &Metadata = {}) { ... }
```

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