[LLVMdev] llvm.meta (was Rotated loop identification)

[Reid Kleckner]

On Thu, Sep 12, 2013 at 4:52 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> > If we only try to solve your immediate problem of
> > builtin_assume_aligned, isn't that good enough for now?
>
> 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:
>
> void foo(double *x) {
>   if (check_if_x_is_special(&global_state)) {
>     y = __builtin_assume_aligned(x, 16);
>     do_something(y);
>   } else
>     do_something_else(x);
> }
>
> 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.
>
> 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?
>
> 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).
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130913/b2d8904c/attachment.html>