[PATCH] D21271: Fix `InstCombine` to not widen metadata on store-to-load forwarding

[Daniel Berlin via llvm-commits]

On Sun, Jun 12, 2016 at 9:31 PM, Yichao Yu <yyc1992 at gmail.com> wrote:

> On Mon, Jun 13, 2016 at 12:18 AM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
> >
> >
> > On Sun, Jun 12, 2016 at 9:04 PM, Yichao Yu <yyc1992 at gmail.com> wrote:
> >>
> >> On Sun, Jun 12, 2016 at 11:48 PM, Daniel Berlin <dberlin at dberlin.org>
> >> wrote:
> >> >
> >> >
> >> > On Sun, Jun 12, 2016 at 8:03 PM, Yichao Yu via llvm-commits
> >> > <llvm-commits at lists.llvm.org> wrote:
> >> >>
> >> >> yuyichao added a comment.
> >> >>
> >> >> In another word, IMHO,
> >> >>
> >> >>   %v1 = load i64, i64 *%p1, !tbaa !0
> >> >>   %v2 = load i64, i64 *%p1, !tbaa !1
> >> >>
> >> >> should be invalid IR (and the optimizer should not be allowed to
> create
> >> >> this) if `!1` and `!2` are non-aliasing tbaa node.
> >> >
> >> > Why?
> >> > It's entirely possible to create a language where this is a valid and
> >> > useful
> >> > lowering.
> >> > TBAA applies *to the load*, not to the *pointer*, and the langref says
> >> > nothing about it requiring it to assign consistent TBAA nodes to
> >> > different
> >> > loads of the same pointer.
> >> >
> >>
> >> My understanding is that the tbaa metadata is used for alias analysis.
> >
> > Yes
> >
> >> What should be the result of the alias analysis on the two loads in
> >> this case?
> >
> >
> > It is valid to say no alias or must-alias.
> >
> >>
> >> Won't
> >> tbaa return no aliasing while some other returns always aliasing for
> >> this case?
> >
> >
> > Yes.
> > This is pretty typical.
> >
> >
> > IE in C,
> >
> > int * foo;
> > float *bar;
> >
> > *bar;
> > foo = (int *)bar;
> > *foo;
> >
> > You have two loads, TBAA will say they do not alias, anything else will
> say
> > they are must-alias.
>
> Isn't this UB with TBAA on in C?
>
>
Yes, it's just an example.


> >
> >
> > In any sane situation, aliasing must be treated as a lattice, and you
> take
> > the "best" answer.
>
> But what's the "best" one?
>

NoAlias


>
> >
> > Alias analysis results should not be confused with value equivalence
> (though
> > it is common).  MustAlias or NoAlias implies nothing about the actual
> > pointer value, only the abstract memory location it represents.
>
> I can understand they are not equivalent but shouldn't not being the
> same pointer value be a necessary condition for NoAlias?


No.  It is a safety condition most pointer analyses use when they know
nothing of the language.
There are both languages and pointer analyses that know enough to say when
the same pointers really do not alias.



> In another
> word, are the following valid?
>
> ```
> define i64 @f1(i64 *%p0, i64 *%p1) {
>   store i64 0, i64 *%p0, !tbaa !0
>   %v2 = load i64, i64 *%p1, !tbaa !1
>   ret %v2
> }
>
> define i64 @f2(i64 *%p1) {
>   store i64 0, i64 *%p1, !tbaa !0
>   %v2 = load i64, i64 *%p1, !tbaa !1
>   ret %v2
> }
>
> %. = call i64 @f(i64 *%p, i64 *%p)
> ```
>

Yes, this is valid.

Assuming !0 and !1 are in different TBAA branches (remember, tbaa is a
tree), it will give noalias.

This means, among other things: Absent any other ordering constraints, you
are free to reorder the load and store relative to each other.

Depending on your interpretation of the langref, it also means you can
eliminate them (because metadata is not supposed to affect semantics).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160613/ceee8201/attachment.html>