[PATCH] D94363: [AA] Pass AAResults through AAQueryInfo
Nikita Popov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 5 12:45:34 PDT 2022
nikic added a comment.
In D94363#3837312 <https://reviews.llvm.org/D94363#3837312>, @asbirlea wrote:
> If you make private the AAR inside AAQI and expose methods only, then instead of calling:
>
> AAQI.AAR.alias(MemoryLocation::getBeforeOrAfter(*CI),
> MemoryLocation::getBeforeOrAfter(Object), AAQI);
>
> you'd call:
>
> AAQI.alias(MemoryLocation::getBeforeOrAfter(*CI),
> MemoryLocation::getBeforeOrAfter(Object), <OptionalNewAAQI>);
>
> I think this is what you meant with "prevent accidentally not passing on AAQI". It's not a huge cleanup though, since there still needs to be an AAQI param for the recursive phi case when a new one's needed.
Yes, that's basically what I had in mind. I don't think the OptionalNewAAQI argument is necessary though, you'd just call it on the new AAQueryInfo instance. The call in https://github.com/llvm/llvm-project/blob/5f7f4846e826f97c7f298fe419c958398d5a0386/llvm/lib/Analysis/BasicAliasAnalysis.cpp#L1449-L1450 would become `UseAAQI->alias(MemoryLocation(...), MemoryLocation(...))`.
> Is this comment outdated, or did we still have a case where the AAR could be null?
>
> /// A pointer to the AAResults object that this AAResult is
> /// aggregated within. May be null if not aggregated.
It can be null if you construct a single AA provider by hand, but not as part of normal usage via the pass manager.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D94363/new/
https://reviews.llvm.org/D94363
More information about the llvm-commits
mailing list