[cfe-dev] [LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)
jabbey at arxan.com
Mon Nov 26 13:43:25 PST 2012
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.
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: http://llvm.org/devmtg/2011-11/#talk2 :-D
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 ( http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023701.html )
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.
On Nov 26, 2012, at 2:26 PM, Jim Grosbach <grosbach at apple.com<mailto:grosbach at apple.com>> wrote:
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.
On Nov 22, 2012, at 3:05 AM, Chandler Carruth <chandlerc at google.com<mailto:chandlerc at google.com>> wrote:
On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com<mailto:geek4civic at gmail.com>> wrote:
s/ExecutionEngine/EE/ (or something like buzzword!)
I don't really know the best bikeshed color here. Jim?
My lame idea would be:
ExecutionEngine -> JIT
ExecutionEngine -> JIT/Legacy
ExecutionEngine/MCJIT -> JIT/MC
ExecutionEngine/OProfileJIT -> JIT/OProfile
ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents
ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld
So long as we have the interpreter, we should keep the ExecutionEngine abstraction around. That said, I'd personally like to kill the interpreter…
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.
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:
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.
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.
(maybe RuntimeDyld -> DynamicLoader ? Too direct?)
I like the current name for RuntimeDyld. That's some of my Darwin bias showing, though.
But not sure this is really an accurate model for the logical layering
of these libraries?
There's a logical layering for these libraries? ;) Seriously speaking, it's pretty close. Close enough that I'm not too worried about it.
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev