[LLVMdev] inttoptr and basicaa

[Dan Gohman]

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.
>

>From the perspective of the compiler, this code is making an outrageous
demand of the compiler. It's doing type punning with the pun obscured by
casting of pointers to integers. That's considered extreme.


> 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).
>

GEP's restrictions make it easier to analyze.


> 2) If the answer to the above is no, then shouldn't basicaa treat the above
> conservatively before it looks at TBAA ?
>

There's no absolute answer to this question. C-style TBAA is a gray area by
its nature.

On one hand, it might make sense to have BasicAA use PartialAlias here (and
relax its definition). That would be a way to say "I don't know" while
still preventing the query from being passed to TBAA.

On the other hand, is this code really worth worrying about, or is the
right answer to just compile it with -fno-strict-aliasing? If the code is
punning with integer-casted pointers, what other things might it be doing
that might cause trouble?

On the third hand, if you are concerned about getting good optimization, it
may be worthwhile to look into rewriting the code to avoid inttoptr and
ptrtoint, since these may be suppressing other optimizations besides.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121109/3899dbba/attachment.html>