[llvm-dev] InstCombine GEP

Nuno Lopes via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 14 04:58:10 PDT 2017


>>> Also, BasicAA has the following rule, with constants c1 and c2, and 
>>> arbitrary values x, y:
>>> a[x][c1] no-alias a[y][c2] if:
>>> the distance between c1 and c2 is sufficient to guarantee that the 
>>> accesses will be disjoint due to ending up in different array slots.
>>> For this rule it's important to know what's the size of each array 
>>> element. This information is lost if GEPs are flattened.
>>
>> Do you mean to say that in LLVM IR we will conclude ptr0 and ptr1 don't 
>> alias:
>>
>>   int a[4][4];
>>   ptr0 = &a[x][3];
>>   ptr1 = &a[y][7];
>>
>> If so, that doesn't match my understanding -- I was under the
>> impression that in LLVM IR x = 2, y = 1 will give us must-alias
>> between ptr0 and ptr1.
>
> No, in this case it won't conclude no-alias, since 3 % 4 == 7 % 4.  LLVM 
> is not that aggressive in exploiting UB.  Anyway, concluding no-alias here 
> was only possible if the GEP index had the inrange attribute.
>
> The example is more like this:
>   int a[4][5];
>   p = &a[x][0];
>   q = &a[y][1];
>
> With access sizes sp, sq, respectively:
> If the access size through p ends before q (q >= sp) and the access 
> through q doesn't go beyond the array limit (sq <= 5*sizeof(int) - 
> 1*sizeof(int)), then it's no-alias.
>
> By flattening a GEP, you lose the information of the size of the each of 
> array/struct constituents. Hence this proof rule doesn't apply and you 
> would get may-alias for the example above.

Let me rephrase this last bit: I agree with you that if the GEP has no 
inrage attributes then there's no logical loss of information: a GEP is 
simply a bunch of arithmetic operations and nothing else can be inferred 
from the types.
However, the BasicAA code that I mentioned above wouldn't kick in (as far as 
I understand).  It would be possible to extend it to handle the flattened 
GEP case, though.  There's already a bit of code that analyses linear 
expressions, but I don't think it go as far as needed to handle the case 
above.

Nuno 



More information about the llvm-dev mailing list