This is an archive of the discontinued LLVM Phabricator instance.

[BasicAA] Include MayBeCrossIteration in cache key
ClosedPublic

Authored by nikic on Oct 18 2022, 7:22 AM.

Details

Summary

Rather than switching to a new AAQI instance with empty cache when MayBeCrossIteration is toggled, include the value in the cache key.

The implementation redundantly include the information in both sides of the pair, but that seems simpler than trying to store it only on one side.

Depends on D136174.

Diff Detail

Event Timeline

nikic created this revision.Oct 18 2022, 7:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 18 2022, 7:22 AM
nikic requested review of this revision.Oct 18 2022, 7:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 18 2022, 7:22 AM

Can you add some explanatory comments into the code please? I'm not entirely sure I understand the caching protocol, and I doubt future readers will. I think this is correct, but I'm not 100% sure on that.

It would also help if you'd explicitly state the invariant relating results with and without the cycle flag. I *think* non-cyclic results should always be at least as precise as the potentially cyclic results. Right? If so, that feels like a valuable thing to note, and (maybe) assert?

llvm/include/llvm/Analysis/AliasAnalysis.h
191–192

Update comment please.

llvm/lib/Analysis/BasicAliasAnalysis.cpp
1409

This appears to have been only use of withEmptyCache, can you remove?

1541–1545

Can you comment this please?

nikic updated this revision to Diff 471166.Oct 27 2022, 7:46 AM
nikic marked 3 inline comments as done.

Remove withEmptyCache(), adjust comments.

nikic added a comment.Oct 27 2022, 7:57 AM

Can you add some explanatory comments into the code please? I'm not entirely sure I understand the caching protocol, and I doubt future readers will. I think this is correct, but I'm not 100% sure on that.

I think for the purposes here, the only thing to know is that anything that influences BasicAA results should be part of the cache key.

It would also help if you'd explicitly state the invariant relating results with and without the cycle flag. I *think* non-cyclic results should always be at least as precise as the potentially cyclic results. Right? If so, that feels like a valuable thing to note, and (maybe) assert?

Conceptually, yes. In practice, this is likely not strictly true in some edge cases. E.g. it could be that the queries start at different depths and one of them hits a depth cutoff and returns a worse result because of that. As such, I don't think we can actually assert it.

Based on your comments, I had the idea that instead of including this in the cache key, we could instead store both Result and ResultInCycle and if we for example determine that Result is MayAlias, we can directly set ResultInCycle to MayAlias as well, because we know it's not going to be better than that. Conversely, if ResultInCycle is NoAlias/MustAlias, we can also set Result based on that. I thought this would be pretty nice, in that it might avoid some redundant calculation. However, we have some pretty complex machinery for invalidating cache entries based on disproven noalias assumptions, and I think getting the interaction there right would be pretty tricky.

reames accepted this revision.Oct 28 2022, 8:56 AM

LGTM

This revision is now accepted and ready to land.Oct 28 2022, 8:56 AM
This revision was landed with ongoing or failed builds.Oct 31 2022, 2:00 AM
This revision was automatically updated to reflect the committed changes.