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

[Daniel Berlin via llvm-commits]

On Sun, Jun 12, 2016 at 10:12 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:

> On Sun, Jun 12, 2016 at 9:31 PM, Yichao Yu <yyc1992 at gmail.com> wrote:
>
>> > 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
>> }
>>
>>
> It depends on what you mean by "valid"... @f1 passed two identical
> pointers is basically equivalent to "ret i64 undef".
>

So, i can't see anything in the langref that says this.

For f1, the valid things i see you can do are (and have an argument you can)

1. move the load before the store, return value of load (IE reorder them)
2. eliminate both the load and store and return 0 (IE forward the store)

I don't see a valid path to ret undef. I'm eminently curious what i've
missed :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160613/072c7d4c/attachment.html>