<div dir="ltr">So,<div>1. I'm about to turn into a pumpkin for about 4 weeks, and not really going to be able to have a serious technical discussion about anything<div>2. The consensus is very clear that everyone is fine with the design Filip proposes. </div>
<div><br></div><div>Given that, i'd suggest y'all just move forward as planned :)</div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 9:18 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>
<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><div class="im"><div>On Oct 11, 2013, at 12:16 AM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:</div>
</div><div class="im"><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">
<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><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><div class="im"><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><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><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>
<div class="im"><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><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>
<div class="im"><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><div>I agree with you in the case of calls.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>-Chris</div></font></span></div></div>
</blockquote></div><br></div>