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

[Daniel Berlin via llvm-commits]

On Mon, Jun 13, 2016 at 8:34 AM, Yichao Yu <yyc1992 at gmail.com> wrote:

> >>
> >> So my original understanding of TBAA (or other metadata that can be
> >> used in alias analysis) is that if two memory operations on the same
> >> runtime path have non intersecting tbaa metadata, they should not
> >> alias.
> >
> >
> > depends on what you mean by "non-intersecting".  TBAA is a set
> hierarchy, so
> > it's possible, given !1 and !2 as tbaa tags, that they do alias, if !2
> is a
> > child of !1 in the tbaa tree.
>
> I mean if !0 and !1 are not child of each other, I was just trying to
> save a few words.....
>

Sure sure :)


>
> >
> >
> >> So maybe a more precise definition is that if two **used**
> >> memory operations on the same runtime path have non intersecting tbaa
> >> metadata, they should not alias. Or in another word, if a load is
> >> never used, then the TBAA on it doesn't count, i.e. LLVM can transform
> >> the code above into
> >>
> >
> > This is a question of whether they are safe to speculatively execute
> (which
> > i believe they are).
> >>
> >> v0 = *p; !dereferencable, !tbaa !0
> >> v1 = *p; !dereferencable, !tbaa !1
> >> if (some_condition)
> >>     v = v0;
> >> else
> >>     v = v1;
> >>
> >> Even though the two loads are on the same runtime path, only one of
> >> them will ever be used so the conflicting tbaa metadata is fine?
> >
> >
> > It doesn't conflict in the first place.
> > You need to stop thinking about this as "a given pointer representing
> some
> > bits can only ever be thought of as referring to one place in memory",
> and
> > "TBAA matters at the llvm level".  TBAA is metadata. You can choose to
> > ignore it or not ignore it. It has no effect on semantics of the loads
> > themselves.
> >
> > TBAA, instead,  is about language level aliasing semantics.  It is saying
> > "even though these loads/stores look the same, they are not to the same
> > memory location" or "even though these loads/stores  look not the same,
> they
> > are the same memory location".
> >
> > It is metadata. You can choose to ignore it or not ignore it, at your
> > leisure. It changes *no semantics*.
> >
>
> Yes, you can ignore them but you can't add them and it should also be
> valid (i.e. not lead to wrong conclusion) if you choose not to ignore
> them.
>

It will not :)


> What I mean by "conflict" or "valid" here are all under the assumption
> that what the optimizer will do if it choose not to ignore them
> (otherwise there's no point of including the metadata).
> Or in another word, whether a pass that uses these metadata (i.e. not
> ignoring them) will do the right thing (i.e. not mis-optimize the
> code), or doing optimizations following the alias analysis using the
> TBAA metadata will indeed not change the schematics.
>
> In that sense I believe having two memory operation on the same
> runtime path with the same pointer value (and same address space and
> everything else) but with TBAA metadata that are not child of each
> other does "conflict" in the sense that the optimizer can do
> transformation based on the TBAA metadata that can change the result
> of the operation (the value loaded).


Yes, but this is what the higher level language has explicitly told us  is
valid to do.
Who are we to argue?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160613/c08be242/attachment.html>