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

[Yichao Yu via llvm-commits]

>>
>> 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.....

>
>
>> 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.
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). The point I'm trying to make
above (and what I want to confirm) is that this does not really change
the schematics (and therefore allowed) if the load that could be
changed by the optimizer will not be used.