[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