[LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)
andrew.kaylor at intel.com
Mon Nov 26 13:47:03 PST 2012
I generally think that the ExecutionEngine renaming/restructuring should be mostly deferred until the legacy stuff goes away.
I do like the idea of at least semi-deprecating the legacy stuff in its name (and can we make that explicit in the documentation too?).
As long as we're renaming things, it we should probably get some consistency between 'OProfile' and 'IntelJITEvents' since both are doing the same thing. I'd also like to see the GDB registration stuff get moved to a JIT event listener, so maybe it would make sense to have something like this:
From: Jim Grosbach [mailto:grosbach at apple.com]
Sent: Monday, November 26, 2012 11:27 AM
To: Chandler Carruth; NAKAMURA Takumi; Kaylor, Andrew
Cc: LLVM Developers Mailing List; clang-dev Developers
Subject: Re: [LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)
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> wrote:
> On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <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.
More information about the llvm-dev