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


In any sane situation, aliasing must be treated as a lattice, and you take
the "best" answer.

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.

--Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160612/8c7e48f3/attachment.html>