<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 13, 2016 at 8:34 AM, Yichao Yu <span dir="ltr"><<a href="mailto:yyc1992@gmail.com" target="_blank">yyc1992@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>><br>
>> So my original understanding of TBAA (or other metadata that can be<br>
>> used in alias analysis) is that if two memory operations on the same<br>
>> runtime path have non intersecting tbaa metadata, they should not<br>
>> alias.<br>
><br>
><br>
> depends on what you mean by "non-intersecting".  TBAA is a set hierarchy, so<br>
> it's possible, given !1 and !2 as tbaa tags, that they do alias, if !2 is a<br>
> child of !1 in the tbaa tree.<br>
<br>
</span>I mean if !0 and !1 are not child of each other, I was just trying to<br>
save a few words.....<br></blockquote><div><br></div><div>Sure sure :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
><br>
><br>
>> So maybe a more precise definition is that if two **used**<br>
>> memory operations on the same runtime path have non intersecting tbaa<br>
>> metadata, they should not alias. Or in another word, if a load is<br>
>> never used, then the TBAA on it doesn't count, i.e. LLVM can transform<br>
>> the code above into<br>
>><br>
><br>
> This is a question of whether they are safe to speculatively execute (which<br>
> i believe they are).<br>
>><br>
>> v0 = *p; !dereferencable, !tbaa !0<br>
>> v1 = *p; !dereferencable, !tbaa !1<br>
>> if (some_condition)<br>
>>     v = v0;<br>
>> else<br>
>>     v = v1;<br>
>><br>
>> Even though the two loads are on the same runtime path, only one of<br>
>> them will ever be used so the conflicting tbaa metadata is fine?<br>
><br>
><br>
> It doesn't conflict in the first place.<br>
> You need to stop thinking about this as "a given pointer representing some<br>
> bits can only ever be thought of as referring to one place in memory", and<br>
> "TBAA matters at the llvm level".  TBAA is metadata. You can choose to<br>
> ignore it or not ignore it. It has no effect on semantics of the loads<br>
> themselves.<br>
><br>
> TBAA, instead,  is about language level aliasing semantics.  It is saying<br>
> "even though these loads/stores look the same, they are not to the same<br>
> memory location" or "even though these loads/stores  look not the same, they<br>
> are the same memory location".<br>
><br>
> It is metadata. You can choose to ignore it or not ignore it, at your<br>
> leisure. It changes *no semantics*.<br>
><br>
<br>
</div></div>Yes, you can ignore them but you can't add them and it should also be<br>
valid (i.e. not lead to wrong conclusion) if you choose not to ignore<br>
them.<br></blockquote><div><br></div><div>It will not :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What I mean by "conflict" or "valid" here are all under the assumption<br>
that what the optimizer will do if it choose not to ignore them<br>
(otherwise there's no point of including the metadata).<br>
Or in another word, whether a pass that uses these metadata (i.e. not<br>
ignoring them) will do the right thing (i.e. not mis-optimize the<br>
code), or doing optimizations following the alias analysis using the<br>
TBAA metadata will indeed not change the schematics.<br>
<br>
In that sense I believe having two memory operation on the same<br>
runtime path with the same pointer value (and same address space and<br>
everything else) but with TBAA metadata that are not child of each<br>
other does "conflict" in the sense that the optimizer can do<br>
transformation based on the TBAA metadata that can change the result<br>
of the operation (the value loaded).</blockquote><div><br></div><div>Yes, but this is what the higher level language has explicitly told us  is valid to do.</div><div>Who are we to argue?<br></div></div></div></div>