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

Yichao Yu via llvm-commits llvm-commits at lists.llvm.org
Sun Jun 12 21:31:13 PDT 2016


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?

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

But what's the "best" one?

>
> 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? 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)
```

>
> --Dan
>
>


More information about the llvm-commits mailing list