<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Oct 11, 2013, at 12:16 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div>There are two possible answers here, depending on the constraints:</div><div><br></div><div>1. The frontend author could unify them into one grand tree, like struct field TBAA does.</div>
</div></blockquote><div><br></div><div>I would be impressed if you could unify the output of something like andersens, and something like the current nested TBAA structure, without massive loss of precision.</div><div>
</div></div></div></div></blockquote><div><br></div><div>To clarify, I have no desire (and I think it would be completely the wrong approach) to represent "points-to" information into the TBAA metadata. Regardless of whether its unification or subset based, this is just *not* the right approach for points-to information.</div><div><br></div><div>I was referring to a frontend that wanted to express source-level aliasing properties through two different TBAA trees for some reason.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>2. The frontend author could model them as two separate TBAA trees, which the TBAA machinery in LLVM handles conservatively.</div>
<div><br></div><div>The conservative handling of different TBAA trees is critical, because you can LTO (for example) Javascript into C++ code in principle, each using their own TBAA structure. LLVM is already well set for this, and it isn't an accident :-)</div>
<div class="im"><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div><div>You also run into issues with the existing metadata on loads/stores in this situation. It's again, entirely possible for a load to conflict with both a tbaa type, and a partitioned heap. In Filip's scheme, there is no way to represent this. </div>
</div></div></div></blockquote><div><br></div></div><div>I'm not sure what you mean. </div></div></blockquote><div><br></div><div>I mean it's not possible, in this scheme, to specify both to be used for disambiguation.</div>
<div><br></div><div>Right now, you get *one* tbaa tag on the load.</div><div>So you have to choose which tree you use if you want if you choose option #2 above.</div><div><br>You always have to choose one or the other, or else the lose the disambiguation.</div></div></div></div></blockquote><div><br></div><div>Correct. This is possible to extend our model to allow multiple tags on loads and stores, but I know of no use case for it, so there is no reason to add the complexity at this point.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div> The compiler will handle this conservatively.</div>
</div></blockquote><div><br></div><div>Only if you drop the tags/disambiguation capability from most things, or i'm seriously confused.</div><div><br></div><div>let's take the following not-quite llvm-ir, but close enough.</div>
<div><br></div><div><br></div><div>!tbaa tree</div><div><br></div><div>0 -> everything</div><div><br></div><div>1 (parent 0) -> int</div><div>2 (parent 0 -> heap a</div><div><br></div><div>load <whatever> , !tbaa 1</div>
<div><br></div><div>call !tbaa.read 2</div><div><br></div><div><br></div><div>Note: You can't specify tbaa.read 2, 1 (at least as proposed).</div><div>the current machinery will say the call and the load never conflict.</div></div></div></div></blockquote><div><br></div><div>I thought you had a general objection about representing the heap partitioning that javascript needs with TBAA information.</div><div><br></div><div>For calls, I agree that you want a mod/ref *set* of different tbaa tags. Having a single tag would definitely not be enough. Perhaps this is why we're talking across each other. I thought you were talking about multiple tags on load/store, and didn't realize you were talking about calls. For calls, I definitely agree you want a set of tags, ideally with "mod, ref, mod+ref" information for each tag.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>I also can't think of a combined tree that would work without massive precision loss.</div></div></div></div></blockquote><div><br></div><div>I agree with you in the case of calls.</div><div><br></div><div>-Chris</div></div></body></html>