[llvm] [BasicAA] Treat IntToPtr(Argument) similarly to Argument in relation to function-local objects. (PR #134505)
David Green via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 7 03:53:56 PDT 2025
davemgreen 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.
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.
(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).
https://github.com/llvm/llvm-project/pull/134505
More information about the llvm-commits
mailing list