<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 10, 2013 at 10:34 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: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 class="im"><div><div>
On Oct 7, 2013, at 11:49 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">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"><div style="word-wrap:break-word"><div><div><br></div><div>
Hence it’s more meaningful to reason about TBAA in terms of its semantics rather than hypothesizing about how and why someone would produce it. </div></div></div></blockquote><div><br></div><div>That would be great, but it's not what the langref says, nor does it match up with the name of the thing you are creating, nor does it necessarily have optimal semantics, nor would it be great for future producers or the ability to do other analyses in those producers.</div>
</div></div></div></blockquote><br></div></div><div>Hey Daniel,</div><div><br></div><div>Can you be more specific about your concerns here?  It's true that we describe the TBAA nodes in terms of expression C-like type constraints, but the intention of the design has always been for it to be more general.  </div>
</div></blockquote><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>
<br></div><div>Specifically, partitioning the heap for use-cases like what Phil is doing with Javascript was factored into the original design.  We have even talked about adding type tags to represent C++ vtables (for example) since language loads and stores can't touch them (not even through char*).</div>
<div><br></div><div>The datastructures and algorithms we have are powerful enough to express these sorts of things, and so long as a frontend abided by the rules, there shouldn't be a problem.</div></div></blockquote>
<div><br></div><div><br class="">My concerns are simply that whether designed this way or not, it ends up fairly inconsistent.<br></div><div><br></div><div>For example, what would the plan be when a frontend does something like clang does now for C/C++ (generate type based TBAA), and also wants to do something like Filip is suggesting (which is also doable on C/C++ with simple frontend analysis)?<br>
</div><div><br>Generate a split tree of some sort, one side of which represents TBAA info, and the other side which represents partitioned abstract heaps?[1]</div><div>It seems like that would be awfully confusing.  </div>
<div><br></div><div>However, it would now be necessary in order to use the new tbaa.read/tbaa.write metadata,, since they will only reference tbaa tags.  But they only make a lot of sense on tbaa tags that point to partitioned heaps like filip's, so if you did want to actually to make use of them, you now have to put both the type info and the heap info in the same tree.</div>
<div><br></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><br></div><div>Because of this, the only thing I essentially asked Filip to do was not place it in the same exact tree as we are currently putting type info into.<br></div><div><br></div><div>Then your heap.read/heap.write metadata works with the heap tree (and you annotate loads/stores with your heap attributes), and your tbaa attributes work on the tbaa tree.  You can tag a load/store with both a heap tag and a tbaa tag, and disambiguate based on both of them.</div>
<div><br></div><div>Now, if the consensus is this is still a good idea, great. My suggestion would then be to update langref, rename the attributes, etc, to make this all more clear.</div><div><br></div><div>--Dan</div><div>
[1]  The other option of trying to generate some fake set of heaps that accurately represent the conflicts in both is, well, difficult :)</div></div></div></div>