<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Oct 10, 2013, at 8:53 PM, 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>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></div></div></blockquote><div><br></div><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>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><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>I'm not sure what you mean. The compiler will handle this conservatively. If you have two different schemas existing in the same application (e.g. due to LTO or due to a language implementing two different non-unified models for some weird reason) then the compiler just doesn't draw any aliasing implications from references using two different schemas.</div><div><br></div><div>It is possible in principle to allow a load (for example) to have an arbitrary number of TBAA tags on it, which would solve this (allowing a single load to participate in multiple non-overlapping schemas) but I don't think it is worth the complexity at all.</div><br></div><div>-Chris</div><br></body></html>