<div dir="ltr">On Thu, Sep 12, 2013 at 4:52 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">> If we only try to solve your immediate problem of<br>
> builtin_assume_aligned, isn't that good enough for now?<br>
<br>
</div></div>The thing that most concerns me about __builtin_assume_aligned and this scheme is the control dependencies. In gcc, it is the return value of the intrinsic that carries the alignment guarantee, and I think that this makes a lot of sense. Consider something like this:<br>

<br>
void foo(double *x) {<br>
  if (check_if_x_is_special(&global_state)) {<br>
    y = __builtin_assume_aligned(x, 16);<br>
    do_something(y);<br>
  } else<br>
    do_something_else(x);<br>
}<br>
<br>
with this scheme, there is never a danger that the alignment assumption can be lifted and incorrectly applied to x in an inlined do_something_else(x). If we simply have the intrinsic not return a value and apply its invariant back on its arguments, then I don't see how to guarantee correctness.<br>

<br>
I would like general invariants, but can I make general invariants return a value in the same way? Alternatively, maybe the invariant could take a pointer and only apply to values in a specific memory location at some particular point? Maybe then AA will keep everything safe?<br>

<br>
As Chandler pointed in response to my original patch on this topic, making the intrinsic return a value means that everyone else needs to look through it. On the other hand, it would make it conservatively correct ;) (as I'm writing this, I'm leaning toward trying the pointer thing).<br>
</blockquote><div><br></div><div>Isn't alignment already annotated on loads and stores?  It seems like the frontend could lower __builtin_assume_aligned() to put the right alignment on all such loads and stores.  An optimization pass could propagate large alignments forward to dominated memory accesses.</div>
<div><br></div><div>If there are no memory accesses (as your example), there's probably nothing to optimize until after inlining, so perhaps there should be an LLVM intrinsic which gets eliminated after inlining, leaving behind no shadow uses.</div>
</div></div></div>