[PATCH] D21271: Fix `InstCombine` to not widen metadata on store-to-load forwarding
Daniel Berlin via llvm-commits
llvm-commits at lists.llvm.org
Mon Jun 13 08:45:36 PDT 2016
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
> > 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
> > bits can only ever be thought of as referring to one place in memory",
> > "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,
> > 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
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...
More information about the llvm-commits