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

[Eli Friedman via llvm-commits]

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".  Whether this is a problem
depends on what the caller does.  (LLVM actually special-cases constructs
like @f2, but that isn't really relevant to this discussion.)

And this is precisely the point: for the sake of simplifying branches and
loops, we want to allow hoisting as much as possible, so LLVM is very
generous about what is actually undefined behavior compared to C.  So you
can load from an uninitialized variable, or load a value using the wrong
TBAA tag, or overflow an addition marked nsw, as long as the behavior of
the program doesn't actually depend on those results.

Given that, there isn't any reason to throw away the TBAA tag when LLVM
hoists (or otherwise inserts) a load.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160612/56e66bab/attachment.html>