llvm dev - Nov 2012 - [LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)

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

(maybe RuntimeDyld -> DynamicLoader ? Too direct?)

But not sure this is really an accurate model for the logical layering
of these libraries?

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:

ExecutionEngine/LegacyJIT
ExecutionEngine/MCJIT
ExecutionEngine/OProfile
ExecutionEngine/IntelJITEvents
ExecutionEngine/RuntimeDyld

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.

-Jim

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.

Cheers,

Joe

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:

ExecutionEngine/LegacyJIT
ExecutionEngine/MCJIT
ExecutionEngine/OProfile
ExecutionEngine/IntelJITEvents
ExecutionEngine/RuntimeDyld

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.

-Jim
_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121126/eb30477b/attachment.html>

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:

ExecutionEngine/EventListeners/OProfile
ExecutionEngine/EventListeners/IntelProfilers
ExecutionEngine/EventListeners/GDB

-Andy

-----Original Message-----
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:

ExecutionEngine/LegacyJIT
ExecutionEngine/MCJIT
ExecutionEngine/OProfile
ExecutionEngine/IntelJITEvents
ExecutionEngine/RuntimeDyld

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.

-Jim