On Thu, Nov 8, 2012 at 6:53 PM, Pranav Bhandarkar <span dir="ltr"><<a href="mailto:pranavb@codeaurora.org" target="_blank">pranavb@codeaurora.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am observing some incorrect behavior in basicaa, wherein two pointers that<br>
basicaa should determine to be MustAlias are ending up NoAlias - the other<br>
extreme :(<br>
I am blaming this on basicaa not handling inttoptr.  Here is the relevant IR<br>
snippet.<br>
--------------------<br>
 %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32<br>
  %sunkaddr37 = add i32 %sunkaddr36, 16<br>
  %sunkaddr38 = inttoptr i32 %sunkaddr37 to i32*<br>
<br>
<br>
<br>
 %sunkaddr39 = ptrtoint %struct.BitParams* %bs to i32<br>
  %sunkaddr40 = add i32 %sunkaddr39, 16<br>
  %sunkaddr41 = inttoptr i32 %sunkaddr40 to i64*<br>
---------------------<br>
<br>
A query to basicaa: alias(%sunkaddr41, 8, %sunkaddr38, 4) results in a<br>
NoAlias return value.<br>
The reason is that nothing inside basicaa processes inttoptr; the fall<br>
through case of using TBAA (int and long long in this case) is executed and<br>
NoAlias is returned as the pointer types are different.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have two questions.<br>
1) Is it safe for basicaa to reason about inttoptr in a manner similar to<br>
aliasGEP (using decomposeGEPExpression to symbolically evaluate the<br>
pointer).<br></blockquote><div><br></div><div>GEP's restrictions make it easier to analyze.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) If the answer to the above is no, then shouldn't basicaa treat the above<br>
conservatively before it looks at TBAA ?<br></blockquote><div><br></div><div>There's no absolute answer to this question. C-style TBAA is a gray area by its nature.</div><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>Dan</div><div><br></div></div>