[PATCH] D92401: [BasicAA] Handle two unknown sizes for GEPs

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 2 09:49:31 PST 2020


nikic added a comment.

In D92401#2427794 <https://reviews.llvm.org/D92401#2427794>, @jdoerfert wrote:

> In D92401#2426503 <https://reviews.llvm.org/D92401#2426503>, @nikic wrote:
>
>> In D92401#2426402 <https://reviews.llvm.org/D92401#2426402>, @jdoerfert wrote:
>>
>>> This kind of logic should always be valid, regardless if V1 is a GEP or not, right? Is there a way to do this check early or late for any query?
>>
>> The general idea is valid, but the way it is applied depends on the operation. For GEPs we just strip to the base pointer. For phis and selects, we recurse over the phi/select operands (with special casing for the case of identical control dependence).
>
> Hm, I'm confused(, but also not deep enough in the BasicAA code to argue). I assumed that this new logic which is put in a function that has a precondition (isa<GEP>(V1)) could be placed in a function without that precondition. The logic does not utilize the fact that V1 isa GEP. Anyway, it was just a thought.

BasicAA first does a stripPointerCastsAndInvariantGroups(). After that operation we are left with either a GEP, a Phi, a Select, or an underlying object (in the sense of something that cannot be further inspected). The BasicAA code thus handles these three cases specially with recursive queries. The reason this is in the GEP code is that we need to strip away the GEP there to arrive at the underlying object. So while isa<GEP> is not directly used, if the value weren't a GEP, then this code wouldn't do anything useful (as we'd have already arrived at the underlying object).

Hope that makes some sense...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92401/new/

https://reviews.llvm.org/D92401



More information about the llvm-commits mailing list