This is an archive of the discontinued LLVM Phabricator instance.

[VPlan] Introduce VPExternalDef specialization for VPValue
Needs ReviewPublic

Authored by sguggill on Jan 11 2021, 9:14 AM.

Details

Reviewers
fhahn
hsaito
Ayal
Summary

The changes here introduce VPExternalDef specialization for VPValues. When constructing VPlan for a candidate loop in the native path, we now create a VPExternalDef when the corresponding underlying value is defined outside the candidate loop.

This change allows us to share the same set of VPExternalDefs in different VPlans constructed for a candidate loop. The sub-class can also be used to infer a VPValue uniformity in VPlan based divergence analysis. These changes will be posted in subsequent follow up patches.

Diff Detail

Event Timeline

sguggill created this revision.Jan 11 2021, 9:14 AM
sguggill requested review of this revision.Jan 11 2021, 9:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 11 2021, 9:14 AM
fhahn added a comment.Jan 24 2021, 6:56 AM

Satish, did you see the recent changes to VPValue, which allows for easy distinction if the value is a live-in or defined in a plan? D92281 added a VPValue::getLiveInIRValue member to access live-in IR values and VPValue::getDef() can be used to check if the value is defined inside a plan. It returns nullptr for live-ins. Given that, I am not sure if the extra class provides enough benefits to justify the additional complexity?

Satish, did you see the recent changes to VPValue, which allows for easy distinction if the value is a live-in or defined in a plan? D92281 added a VPValue::getLiveInIRValue member to access live-in IR values and VPValue::getDef() can be used to check if the value is defined inside a plan. It returns nullptr for live-ins. Given that, I am not sure if the extra class provides enough benefits to justify the additional complexity?

Hi Florian, I will try to refactor these patches using the recent VPValue changes. Thanks!