<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; ">My use-case of LLVM is susceptible to breaking when there are changes in names. While I don't have a particular preference, I think efforts to have names more intuitively describe their internals is great. This will help newcomers find their way, and since LLVM is growing... reducing the overhead to "get" LLVM's internals will help promote that growth.<div><br></div><div>Back to my use-case, I care about being able to rapidly adapt to new names when they are decided and, most importantly, once committed. As such, this discussion reminds me of a talk at the 2011 LLVM conference: <a href="http://llvm.org/devmtg/2011-11/#talk2">http://llvm.org/devmtg/2011-11/#talk2</a> :-D</div><div><div><div><br></div><div>Using/providing a set of Matchers for the internal renaming that would be applicable to out-of-tree projects sure seems like a good use case. Once the bikeshed(s) color(s) is(are) determined, I'd be happy to work on a tool to be included in official clang tools ( <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023701.html">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023701.html</a> )</div><div><br></div><div>Of course if it's just renaming directories, that requires nothing more than a few lines of (favorite scripting language) to update includes and possibly some build files. But if we're actually renaming class, methods etc... Matchers sure seem to be a useful way to do things.</div><div><br></div><div>Cheers,</div><div><br></div><div>Joe</div><div><div apple-content-edited="true">
</div>
<br><div><div>On Nov 26, 2012, at 2:26 PM, Jim Grosbach <<a href="mailto:grosbach@apple.com">grosbach@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Catching up on post-holiday emails. I may have comments on the more general stuff later, but wanted to respond to this bit more quickly.<br><br>On Nov 22, 2012, at 3:05 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br><br><blockquote type="cite">On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <<a href="mailto:geek4civic@gmail.com">geek4civic@gmail.com</a>> wrote:<br><blockquote type="cite">s/ExecutionEngine/EE/ (or something like buzzword!)<br></blockquote><br>I don't really know the best bikeshed color here. Jim?<br><br>My lame idea would be:<br><br>ExecutionEngine -> JIT<br>ExecutionEngine -> JIT/Legacy<br>ExecutionEngine/MCJIT -> JIT/MC<br>ExecutionEngine/OProfileJIT -> JIT/OProfile<br>ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents<br>ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld<br><br></blockquote>So long as we have the interpreter, we should keep the ExecutionEngine abstraction around. That said, I'd personally like to kill the interpreter…<br><br>Eventually, lots of this can (and should) be simplified and flattened as the obsolete bits get deleted (legacy JIT and hopefully the interpreter). That's a re-org for another day, though, and is more than just moving files around.<br><br>On the way to that, though, I really like your idea of making the legacy status of the old JIT explicit in the structure. I would suggest the fairly minor restructuring of:<br><br>ExecutionEngine/LegacyJIT<br>ExecutionEngine/MCJIT<br>ExecutionEngine/OProfile<br>ExecutionEngine/IntelJITEvents<br>ExecutionEngine/RuntimeDyld<br><br>When the old JIT goes away, we "rm -rf LegacyJIT". When the interpreter goes away (assuming that's something we go forward with), the whole ExecutionEngine structure becomes "JIT" and everything flattens.<br><br>Bottom line for me is that I don't mind the naming of most of this stuff as-is, but I very much would like to see some simplification, renaming and restructuring as the MCJIT pushes forwards and old broken stuff gets nuked.<br><br><blockquote type="cite">(maybe RuntimeDyld -> DynamicLoader ? Too direct?)<br></blockquote><br>I like the current name for RuntimeDyld. That's some of my Darwin bias showing, though.<br><br><blockquote type="cite">But not sure this is really an accurate model for the logical layering<br>of these libraries?<br></blockquote><br>There's a logical layering for these libraries? ;) Seriously speaking, it's pretty close. Close enough that I'm not too worried about it.<br><br>-Jim<br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></div></div></div></body></html>