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

[Yichao Yu via llvm-commits]

>> 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 lavel language has explicitly told us is
> valid to do.
> Who are we to argue?

Well, in this case, it's about whether LLVM can generate this so we are
arguing with the optimizer. I think the explaination that I want to confirm
should be relatively close and can explain why the merge of the metadata is
the right solution so Ill just use it until I hit another case that it
doesnt work.....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160613/ea61bbb4/attachment.html>