[LLVMdev] inttoptr and basicaa

[Eli Friedman]

On Thu, Nov 8, 2012 at 6:53 PM, Pranav Bhandarkar
<pranavb at codeaurora.org> wrote:
> Hi,
>
> I am observing some incorrect behavior in basicaa, wherein two pointers that
> basicaa should determine to be MustAlias are ending up NoAlias - the other
> extreme :(
> I am blaming this on basicaa not handling inttoptr.  Here is the relevant IR
> snippet.
> --------------------
>  %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32
>   %sunkaddr37 = add i32 %sunkaddr36, 16
>   %sunkaddr38 = inttoptr i32 %sunkaddr37 to i32*
>
>
>
>  %sunkaddr39 = ptrtoint %struct.BitParams* %bs to i32
>   %sunkaddr40 = add i32 %sunkaddr39, 16
>   %sunkaddr41 = inttoptr i32 %sunkaddr40 to i64*
> ---------------------
>
> A query to basicaa: alias(%sunkaddr41, 8, %sunkaddr38, 4) results in a
> NoAlias return value.
> The reason is that nothing inside basicaa processes inttoptr; the fall
> through case of using TBAA (int and long long in this case) is executed and
> NoAlias is returned as the pointer types are different.
>
> I have two questions.
> 1) Is it safe for basicaa to reason about inttoptr in a manner similar to
> aliasGEP (using decomposeGEPExpression to symbolically evaluate the
> pointer).

If we can prove the difference between two pointer values is a
compile-time constant (in this case, zero), we can return
NoAlias/MustAlias/etc. based purely on that.  That said, GEP makes
special aliasing guarantees which are impossible to reconstruct from
inttoptr.

-Eli