Similar to other patches like D84680, this makes VPWidenRecipe a VPValue. Because of the way it interacts with the reduction code it also slightly alters the way that VPValues are registered, removing the up front NeedDef and using getOrAddVPValue to create them on-demand if needed instead.
Thanks for putting up this patch. This is indeed a conversion that also needs to be done and for which I didn't put up patches in the series.
Some comments inline. I think this might also need a rebase.
WidenRecipe is always guaranteed to be a VPValue here because it is either a VPWidenSelect or VPWiden recipe, right? I think it should be possible to call toVPValue unconditionally, or better just cast<VPValue>(WidenRecipe), possible with a comment why it is safe?
We also need to update widenInstruction to update State to register the result for the VPValue (replace VectorLoopValueMap.setVectorValue(&I, Part, V); with something like State.set(Def, &I, V, Part);, where Def is the VPValue of the widen recipe.
I think this needs updating to print something like VPValue result = Opcode VPValue operands.
Should be possible by using printAsOperand(O, SlotTracker) for the VPValue result, Instruction::getOpcodeName for the opcode and printOperands for the operands.
Rebase and address comments
Yeah this was written before VPWidenSelect went in.
This all relies on changing VPReductionRecipe first I think. As you can imagine, as these are already actually using VPValues, they become the most interrelated recipes to change.
I think this is the only user of addOrReplaceVPValue. If so, it would be good to remove it.
cast<VPValue>(RedRecipe) should not be needed, because RedRecipe is of type VPReductionRecipe, which in turn inherits from VPValue?
Thanks! There's now a printOperands() function that could be used to print the operands here.
OK. Thanks for the review. Lets give this a go and see if anything complains. I've managed to run a sanitized build successfully at least, but let me know if anything else doesn't work.