[llvm] [BasicAA] Treat IntToPtr(Argument) similarly to Argument in relation to function-local objects. (PR #134505)
Nikita Popov via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 7 12:40:21 PDT 2025
nikic wrote:
> > In test3, if %Q_as_int == ptrtoint(%P) and %P has escaped (and thus its provenance may be exposed), then inttoptr(%Q_as_int) may alias %P.
>
> OK. There is likely something wrong with my head-canon on aliasing and provenance, it is quite a complex subject that I understand hasn't necessarily been nailed down yet. I think the one I am interested in is aliasing between allocas that escape and coerced args, not noalias args (although the case I am looking at contains both).
>
> Is it just for noalias args that this would be incorrect, or allocas too? I think the thing I don't understand is how the parent call could have `%Q_as_int == ptrtoint(%P)` validly if it was a truly local object. https://godbolt.org/z/Trbb8TM9c. At best it could reference the %P from a _previous_ invocation of the call, which is a different %P and so %Q = inttoptr cannot be based on this %P.
The situation for allocas is pretty similar. Adjusting the example from https://github.com/llvm/llvm-project/pull/134505/files/1c308aa8adf9ddb03726d2d35dfa1689a438f8d5#r2031886105 you get (using C only for brevity):
```
void test(uintptr_t Q_as_int) {
int P = 0;
if ((uintptr_t)&P == Q_as_int) {
(int *)Q_as_int = 1; // Can alias P.
printf("%d", P);
}
}
```
This function can either do nothing or print 1, but it can't print 0. The caller does not know the address of P, but it could still just guess luckily.
> Or is it that inttoptr recreates provenance at the current time it is executed from address, and so (along with 33896) inttoptrs can have some level of side-effects and cannot be moved past an alloc call? i.e. we are aiming for a pvni-ae model even if we are not there yet.
Yes, some kind of pnvi-ae style model is my current operating assumption.
> (I might be able to change how the arguments are coerced, side-stepping all of this. It wouldn't work in all cases, I need to check).
Changing argument coercion would be ideal. No matter how you turn it, passing pointers though integers will always do bad things with provenance.
https://github.com/llvm/llvm-project/pull/134505
More information about the llvm-commits
mailing list