This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Introduce code to limit querying VPValues using IR references.
ClosedPublic

Authored by fhahn on Aug 23 2021, 12:34 PM.

Details

Summary

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

  1. truncateToMinimalBitwidths
  2. clearReductionWrapFlags
  3. fixLCSSAPHIs

As a first step, this flag will help preventing new code from violating
this property.

Any suggestions with respect to naming very welcome!

Diff Detail

Event Timeline

fhahn created this revision.Aug 23 2021, 12:34 PM
fhahn requested review of this revision.Aug 23 2021, 12:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 23 2021, 12:34 PM
Herald added a subscriber: vkmr. · View Herald Transcript
Ayal added a comment.Aug 24 2021, 2:35 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
9489

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?

llvm/lib/Transforms/Vectorize/VPlan.h
2150

disableGetVPValue()?

Some related thoughts: should addVPValue() and removeVPValue() also be disallowed, i.e., disable all accesses to Value2VPValue? Conceptually, Value2VPValue can be destroyed, and potentially another type of VPlan which does not support Value2VPValue created and provided instead.

fhahn updated this revision to Diff 368622.Aug 25 2021, 6:35 AM

Thanks for taking a look! I changed the name to Value2VPValueOutdated & added assertions to addVPValueFor and removeVPValue.

fhahn updated this revision to Diff 368623.Aug 25 2021, 6:43 AM

Adjust naming again to`Value2VPValueEnabled`.

fhahn added inline comments.Aug 25 2021, 6:45 AM
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
9489

I'm not sure, introduction of FirstOrderRecurrenceSplice could also be moved after disallowing Value2VPValue access, but it is not an optimization. Should we do the potential split separately, to keep the diff smaller?

llvm/lib/Transforms/Vectorize/VPlan.h
2150

Some related thoughts: should addVPValue() and removeVPValue() also be disallowed, i.e., disable all accesses to Value2VPValue

Sounds good! I added assertions there and renamed the code to use disableValue2VPValue/Value2VPValueEnabled.

Conceptually, Value2VPValue can be destroyed, and potentially another type of VPlan which does not support Value2VPValue created and provided instead.

Agreed, once the offending pieces of code have been removed, we can clear the map instead.

Ayal accepted this revision.Aug 25 2021, 8:52 AM

This looks good to me, thanks for following-up!

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
9489

Sure, refactoring can be done separately. And indeed may include non-optimization stages that are pure VPlan2VPlan transformations.

llvm/lib/Transforms/Vectorize/VPlan.h
2193

Note that calling getOrAddVPValue() with OverrideAllowed allows to get a VPValue but not add one. This is fine, as the override is temporary anyhow.

This revision is now accepted and ready to land.Aug 25 2021, 8:52 AM