This is an archive of the discontinued LLVM Phabricator instance.

[DSE,MemorySSA] Use BatchAA for AA queries.
ClosedPublic

Authored by fhahn on Aug 20 2020, 3:00 AM.

Details

Summary

We can use BatchAA to avoid some repeated AA queries. We only remove
stores, so I think we will get away with using a single BatchAA instance
for the complete run.

The changes in AliasAnalysis.h mirror the changes in D85583.

The change improves compile-time by roughly 1%.
http://llvm-compile-time-tracker.com/compare.php?from=67ad786353dfcc7633c65de11601d7823746378e&to=10529e5b43809808e8c198f88fffd8f756554e45&stat=instructions

This is part of the patches to bring down compile-time to the level
referenced in
http://lists.llvm.org/pipermail/llvm-dev/2020-August/144417.html

Diff Detail

Event Timeline

fhahn created this revision.Aug 20 2020, 3:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 20 2020, 3:00 AM
fhahn requested review of this revision.Aug 20 2020, 3:00 AM

The improvement looks great!

The alias cache relies on MemoryLocations and should be valid. The nonEscaping cache relies on pointers, so here I had reservations on what happens if a store is in cache and gets removed. There are no future queries for it, and there are no new values in DSE that may reuse that pointer. So I *think* this is correct, but it needs some documentation in the pass on why BatchAA is ok to use here.
I think it's necessary for the assumptions to be made clear in case the pass changes for some reason and breaks those assumptions; also if new caches are added in BatchAA, its users should have it clearly specified on what behavior they rely.

fhahn updated this revision to Diff 287054.Aug 21 2020, 9:38 AM

The improvement looks great!

Yep, but just to note, this improvements is already included in the numbers shared on llvm-dev.

The alias cache relies on MemoryLocations and should be valid. The nonEscaping cache relies on pointers, so here I had reservations on what happens if a store is in cache and gets removed. There are no future queries for it, and there are no new values in DSE that may reuse that pointer. So I *think* this is correct, but it needs some documentation in the pass on why BatchAA is ok to use here.
I think it's necessary for the assumptions to be made clear in case the pass changes for some reason and breaks those assumptions; also if new caches are added in BatchAA, its users should have it clearly specified on what behavior they rely.

That makes sense! I added a comment to the BatchAA member in DSEState. Do you think that is sufficient?

asbirlea accepted this revision.Aug 21 2020, 1:32 PM

Yes, that looks good to me, thank you!

This revision is now accepted and ready to land.Aug 21 2020, 1:32 PM
This revision was landed with ongoing or failed builds.Aug 22 2020, 12:45 AM
This revision was automatically updated to reflect the committed changes.