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

Hello LLVM & Clang hackers!

Based on a discussion with Chris, I would like to propose a Great
Renaming of Things for the 3.3-era LLVM and Clang codebase.

First and foremost, the two most significant changes I would like to make:

1) llvm/lib/VMCore/... -> llvm/lib/IR/...

I've discussed potential names for the VMCore (or LLVMCore) library
with lots of folks, and the best idea anyone has was Chris's initial
suggestion: IR. So I'd like to minimize the bikeshed discussions on
this one. ;]

There is one interesting question here: should we move
include/llvm/*.h to include/llvm/IR/*.h to match other libraries?


2) clang/lib/CodeGen/... -> clang/lib/IRGen/...

I think this name is so painfully obvious that everyone will be happy
with this change...

... because it's the biggest change. It will involve a great deal of
renaming (CodeGenFunction for example) in order to keep things
consistent.


Are there other names that are poor choices and are lingering in our
codebases? I'm willing to sign up to do more renames while I'm at
this, so this is a chance to get someone else to do the heavy lifting.
=]

2012/11/22 Chandler Carruth <chandlerc at
google.com>:
> Hello LLVM & Clang hackers!
>
> Based on a discussion with Chris, I would like to propose a Great
> Renaming of Things for the 3.3-era LLVM and Clang codebase.
>
> First and foremost, the two most significant changes I would like to make:
>
> 1) llvm/lib/VMCore/... -> llvm/lib/IR/...
>
> I've discussed potential names for the VMCore (or LLVMCore) library
> with lots of folks, and the best idea anyone has was Chris's initial
> suggestion: IR. So I'd like to minimize the bikeshed discussions on
> this one. ;]
Oh I missed the discussion. I prefer "Core." Yes, bikeshed.
> There is one interesting question here: should we move
> include/llvm/*.h to include/llvm/IR/*.h to match other libraries?
IMHO, we may keep include/llvm/*. They should be essential interfaces.
> 2) clang/lib/CodeGen/... -> clang/lib/IRGen/...
>
> I think this name is so painfully obvious that everyone will be happy
> with this change...
>
> ... because it's the biggest change. It will involve a great deal of
> renaming (CodeGenFunction for example) in order to keep things
> consistent.
No objection to rename them consistent.
IMO, I am tolerant of *historical namings*.
> Are there other names that are poor choices and are lingering in our
> codebases? I'm willing to sign up to do more renames while I'm at
> this, so this is a chance to get someone else to do the heavy lifting.
> =]
s/AsmParser/IRASM/ (to be distinguished against MCASM)
s/ExecutionEngine/EE/ (or something like buzzword!)


...Takumi

On 11/22/12 04:53 PM, NAKAMURA Takumi wrote:
> 2012/11/22 Chandler Carruth<chandlerc at google.com>:
>> Hello LLVM&  Clang hackers!
>>
>> Based on a discussion with Chris, I would like to propose a Great
>> Renaming of Things for the 3.3-era LLVM and Clang codebase.
>>
>> First and foremost, the two most significant changes I would like to
make:
>>
>> 1) llvm/lib/VMCore/... ->  llvm/lib/IR/...
(-1 karma to self for participating in bikeshed)

I'm not sure how and if this change would affect my group, but I'd have 
a slight preference to llvm/lib/LLVMIR/
-----------
While the current naming may not be the best I'm -1 for the change in 
general.

On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com>
wrote:
> 2012/11/22 Chandler Carruth <chandlerc at google.com>:
>> Hello LLVM & Clang hackers!
>>
>> Based on a discussion with Chris, I would like to propose a Great
>> Renaming of Things for the 3.3-era LLVM and Clang codebase.
>>
>> First and foremost, the two most significant changes I would like to
make:
>>
>> 1) llvm/lib/VMCore/... -> llvm/lib/IR/...
>>
>> I've discussed potential names for the VMCore (or LLVMCore) library
>> with lots of folks, and the best idea anyone has was Chris's
initial
>> suggestion: IR. So I'd like to minimize the bikeshed discussions on
>> this one. ;]
>
> Oh I missed the discussion. I prefer "Core." Yes, bikeshed.
I dislike 'Core' and all other overly generic names. Specifically, why
is Support not Core? Or vice versa? I would like a name that actually
represents the principle organizing component, and that component in
this case is the C++ APIs making up the IR of the compiler.

>> There is one interesting question here: should we move
>> include/llvm/*.h to include/llvm/IR/*.h to match other libraries?
>
> IMHO, we may keep include/llvm/*. They should be essential interfaces.
I dislike the inconsistency of the include tree and the lib tree. When
that inconsistency is just collapsing an entire directory to a single
file, it seems fine and even good when the names align. But this seems
somewhat less principled than that.

Essentially, consistency is a strong argument. I'm looking for strong
arguments for keeping them where they are to counter that.

> s/AsmParser/IRASM/ (to be distinguished against MCASM)
This is a really good one.

I would paint this bikeshed LLParser or IRParser. "Asm" has to go
though.

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?

> Are there other names that are poor choices and are lingering in our
> codebases? I'm willing to sign up to do more renames while I'm at
> this, so this is a chance to get someone else to do the heavy lifting.
That TargetLowering/ISelLowering indecision is a little annoying in
the backends occasionally.

Tim.

On Thu, Nov 22, 2012 at 12:56 AM, Chandler Carruth <chandlerc at
google.com> wrote:
> Hello LLVM & Clang hackers!
>
> Based on a discussion with Chris, I would like to propose a Great
> Renaming of Things for the 3.3-era LLVM and Clang codebase.
>
> First and foremost, the two most significant changes I would like to make:
>
> 1) llvm/lib/VMCore/... -> llvm/lib/IR/...
I strongly support this.
>
> I've discussed potential names for the VMCore (or LLVMCore) library
> with lots of folks, and the best idea anyone has was Chris's initial
> suggestion: IR. So I'd like to minimize the bikeshed discussions on
> this one. ;]
>
> There is one interesting question here: should we move
> include/llvm/*.h to include/llvm/IR/*.h to match other libraries?
Yes. Very much so. There should be no headers in include/llvm/.
>
>
> 2) clang/lib/CodeGen/... -> clang/lib/IRGen/...
Agreed
>
> I think this name is so painfully obvious that everyone will be happy
> with this change...
>
> ... because it's the biggest change. It will involve a great deal of
> renaming (CodeGenFunction for example) in order to keep things
> consistent.
>
>
> Are there other names that are poor choices and are lingering in our
> codebases? I'm willing to sign up to do more renames while I'm at
> this, so this is a chance to get someone else to do the heavy lifting.
> =]
I really dislike that all the files and classes in the MC library
start with MC. This is c++, not c :(


- Michael Spencer

> I really dislike that all the files and classes in the MC library
> start with MC. This is c++, not c :(
Same here.
>
> - Michael Spencer
Cheers,
Rafael

>> Are there other names that are poor choices and are lingering in our
>> codebases? I'm willing to sign up to do more renames while I'm
at
>> this, so this is a chance to get someone else to do the heavy lifting.
>> =]
>
> I really dislike that all the files and classes in the MC library
> start with MC. This is c++, not c :(
>
While I agree with the general sentiment, I would be wary of
overloading *core* LLVM concepts for the sake of naming purity. Should
we really have one Instruction for IR, one for the MachineInstr level
and one for MC? IR::Instruction, Machine::Instruction and
MC::Instruction may be reasonable to spell out in code, but not very
helpful for discussing and reading about these concepts. For such key
LLVM concepts, I actually find the separation useful.

Eli

Lacking any dissenting opinions, I wanted to give a heads up to folks:

I plan to do the two major renamings I mentioned above this weekend.
I'll do it over the weekend to try to minimize the number of patches
that folks have outstanding touching files in those trees.

I'll respond later this week with more details to help sort out any
last questions of naming. It looks like the only real bikeshed left is
the name for the CodeGen classes, and I'll mostly defer to John's
whims there as he has to read and touch that code more than most
others. =]

On Thu, Nov 22, 2012 at 12:56 AM, Chandler Carruth <chandlerc at
google.com> wrote:
> Hello LLVM & Clang hackers!
>
> Based on a discussion with Chris, I would like to propose a Great
> Renaming of Things for the 3.3-era LLVM and Clang codebase.
>
> First and foremost, the two most significant changes I would like to make:
>
> 1) llvm/lib/VMCore/... -> llvm/lib/IR/...
>
> I've discussed potential names for the VMCore (or LLVMCore) library
> with lots of folks, and the best idea anyone has was Chris's initial
> suggestion: IR. So I'd like to minimize the bikeshed discussions on
> this one. ;]
>
> There is one interesting question here: should we move
> include/llvm/*.h to include/llvm/IR/*.h to match other libraries?
>
>
> 2) clang/lib/CodeGen/... -> clang/lib/IRGen/...
>
> I think this name is so painfully obvious that everyone will be happy
> with this change...
>
> ... because it's the biggest change. It will involve a great deal of
> renaming (CodeGenFunction for example) in order to keep things
> consistent.
>
>
> Are there other names that are poor choices and are lingering in our
> codebases? I'm willing to sign up to do more renames while I'm at
> this, so this is a chance to get someone else to do the heavy lifting.
> =]

On Nov 28, 2012, at 1:34 AM, Chandler Carruth <chandlerc at google.com>
wrote:
> Lacking any dissenting opinions, I wanted to give a heads up to folks:
> 
> I plan to do the two major renamings I mentioned above this weekend.
> I'll do it over the weekend to try to minimize the number of patches
> that folks have outstanding touching files in those trees.
Sounds good.  For the LLVM side change, please a list of destinations for the
new header file structure and the class renamings you want to do.  I'd
really prefer things to move *once* to their final location, not keep dancing
around to different locations if we change our minds and discuss things :)
> I'll respond later this week with more details to help sort out any
> last questions of naming. It looks like the only real bikeshed left is
> the name for the CodeGen classes, and I'll mostly defer to John's
> whims there as he has to read and touch that code more than most
> others. =]
I'm happy to let the clang folks figure out the best way to handle this.  As
a small request if this sort of thing happens again (and not *that* big of a
deal), it would have been nice if your original email was two different emails
sent to llvmdev and cfe-dev for the halves of the proposal relevant to each
community - instead of cross posting them both.  If nothing else, it's a
pain for list moderation :)

-Chris