[PATCH] D101541: BasicAA: Recognize inttoptr as isEscapeSource

[Joseph Tremoulet via Phabricator via llvm-commits]

JosephTremoulet added a comment.

In D101541#2727752 <https://reviews.llvm.org/D101541#2727752>, @aqjune wrote:

> `isNonEscapingLocalObject` returns true if the pointer is a noalias argument, and it's worth clarifying why this is okay somewhere.
>
> The noalias argument case is slightly different from other cases because its address could have been ptrtoint-ed already. For example:
>
>   %i = ptrtoint i8* %ptr0 to i64
>   call void @f(i8* %ptr0, i64 %i)
>   
>   define void @f(i8* noalias %ptr, i64 %i) {
>     ; access %ptr <- isNonEscapingLocalObject(%ptr) is true, but
>     ; access inttoptr(%i) <- this can exactly touch %ptr.
>   }
>
> It isn't clear whether the second access is successfully done according to the definition of based-on in LangRef.
> Should we clarify that noalias ptr (`%ptr`) is not based on the original pointer (`%ptr0`)?

By my read, it isn't that %ptr isn't based on %ptr0 (I think it is based on %ptr0, though the LangRef based-on definition doesn't explicitly address copies from call arguments/parameters/returns, phis, selects, extractelement/extractvalue, etc.; maybe it should?).
Rather, I think that it's this language in the definition of noalias:

>   This indicates that memory locations accessed via pointer values
>    :ref:`based <pointeraliasing>` on the argument or return value are not also
>    accessed, during the execution of the function, via pointer values not
>    *based* on the argument or return value. ... The caller shares the responsibility with the callee for
>    ensuring that these requirements are met.

which means that the example you show is an incorrect use of the noalias attribute, because of the access via inttoptr(%i), which is not based on %ptr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101541