This is an archive of the discontinued LLVM Phabricator instance.

Make TBAA information to be part of LValueBaseInfo
AbandonedPublic

Authored by kosarev on Sep 21 2017, 2:47 AM.

Details

Summary

This patch incorporates TBAA information into LValueBaseInfo to they can be propagated as a whole. It shouldn't contain any functional changes.

Diff Detail

Event Timeline

kosarev created this revision.Sep 21 2017, 2:47 AM

Please make sure to add the mailing list as a subscriber when you post a patch. (I haven't looked at the patch yet.)

Sure, will do. Just added it to D38074. Thanks.

kosarev updated this revision to Diff 118045.Oct 6 2017, 11:30 AM
kosarev edited the summary of this revision. (Show Details)

Re-based on top of the previous refinements: D38404, D38408, D38456, D38460, D38503 and D37826. Still large, but most of the changes are local and trivial. Please let me know if it is too complex to be reviewed. Thanks.

kosarev added inline comments.Oct 6 2017, 11:41 AM
lib/CodeGen/CodeGenModule.cpp
55 ↗(On Diff #118045)

Oops. Will be removed.

kosarev updated this revision to Diff 118200.Oct 9 2017, 4:43 AM

Removed the extra #include.

Please take a look at D38695, if you want this by smaller pieces. Thanks.

kosarev updated this revision to Diff 119373.Oct 17 2017, 12:50 PM
kosarev edited the summary of this revision. (Show Details)

Rebased on top of D39008 and ready for review.

rjmccall edited edge metadata.Oct 23 2017, 1:01 AM

Hmm. I'm not sure I like the design of merging TBAAAccessInfo into LValueBaseInfo. LValueBaseInfo is currently the set of information that's generally preserved across l-value manipulations. It was extracted from LValue specifically to create an encapsulated entity that can just be mindlessly propagated in most of that code. But if you merge TBAA information into it, then l-value manipulations need to be aware of its contents, in the same way they have to be aware of everything else they're storing in the new LValue. The fact that code needs to be aware of it suggests it should continue to be an explicit argument, or at the very least be combined with something else that l-value manipulations generally already need to be aware of, like the type.

kosarev abandoned this revision.Oct 25 2017, 7:21 AM

Indeed, if LValueBaseInfo is what we know about the very first value in a sequence, then TBAA info certainly should not be part of it. This also means whatever is specified as a direct base lvalue to the lvalue we are constructing should probably be passed as LValue, as suggested in D39177.

Thanks!