After applying VPlan-to-VPlan transformations, using IR references to
query VPlan values may be incorrect, as the IR is not in sync with the
VPlan any longer.
To better detect such mis-matches, this patch introduces a new flag to
VPlans to indicate whether it is safe to query VPValues using IR values.
getVPValue is updated to assert if it is called when the flag indicates
it is not safe any longer.
There is an escape hatch via an extra argument, because there are 3
places that need to be fixed first. Those are
- truncateToMinimalBitwidths
- clearReductionWrapFlags
- fixLCSSAPHIs
As a first step, this flag will help preventing new code from violating
this property.
Any suggestions with respect to naming very welcome!
Perhaps refactor to have buildVPlanWithVPRecipes() take care of building the initial unoptimized VPlan only, ending with marking IRToVPlan disallowed. I.e., invoke sinkScalarOperands() and mergeReplicateRegion() optimizations after buildVPlanWithVPRecipes() returns?