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.
=]

It seems like a good opportunity to make the capitalization of functions consistent. I suppose local variables are too much work, but functions would be a nice start. (Still an enormous amount of work.)

Sebastian

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

(-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/

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.

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?

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/

I'm pretty opposed to repeating LLVM in the name of any directory...
There's absolutely no ambiguity here.

While the current naming may not be the best I'm -1 for the change in
general.

Are there any serious reasons or concerns? I'm well aware that this
will impose a cost on out-of-tree projects, but on the whole it should
be pretty minimal and consist of some applications of 'sed'.

I think renaming large libraries and layers whose names are poor is
actually less churn, and significantly more benefit for the churn. I'd
like to not cross the bridge of automatically reformatting any of the
source code until we can reformat *all* of the source code with the
automated formatting tools under development.

(Still an enormous amount of work.)

Not if you use a sufficiently smart tooling helper - I can see one for function naming being not particularly difficult.

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.

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.

I agree. LLVM IR exists in a layer of a very big stack, including clang, lldb, compiler_rt, etc. it's a very *important* layer, but calling it "core" is just misleading and non-descriptive.

Part of my motivation of naming it "IR" is that it makes it really clear what should be in there. Also, the only stuff that would move to include/llvm/IR are the things related to IR: the other stuff should be left where they are for now, but eventually move. For example: passmanager to transforms(?), Intrinsics to targets, Intrinsics to targets, AutoUpgrade to transforms, and AddressingMode.h somewhere not there :slight_smile:

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.

Right. IR is central to the compiler backend, but clients of clang or higher level things (who do use a lot of stuff from llvm/* also, directly) don't necessarily use IR).

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.

Personally, I'd like to get llvm/IR and CodeGen->IRGen done, then discuss other movements in separate threads :). But yes, there is a lot of progress that could be made here.

-Chris

Hi,

  Chandler, could you post headup on the list while doing the renaming?
That would be helpful. =]

Regards,
chenwj

Also, this is a mistake that I got right with clang: note that clangs "core" API is in include/clang/AST, not in include/clang.

-Chris

>> 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.

+1 for moving the IR headers into their own sub-directory. This was (is)
definitely messing with my OCD!

Thanks to clarify. It makes sense.

That said, shall we not rename s/VMCore/IR/, but split individual
stuff in VMCore into each, step-by-step?

...Takumi

Well, it's a bit more serious than that if an out-of-tree project tries
to support older LLVM versions (e.g., Pure still supports all LLVM
versions >= 2.5). Alas, most popular Linux distributions still package
old LLVM versions (e.g., Ubuntu 12.04 LTS has LLVM 2.9, and this will
still be around for a long time). That's something we poor out-of-tree
projects just have to live with if we don't want to tell our users to
compile their own LLVM from source.

I've learned how to live with the frequent C++ API changes, but in any
case it would be nice if these name changes are documented meticulously
so that 3.3 doesn't become a veritable nightmare for 3rd party projects. :wink:

Albert

One solution to this is to use "computed" #includes that come from macro expansions.

-Chris

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 :frowning:

- Michael Spencer

I really dislike that all the files and classes in the MC library
start with MC. This is c++, not c :frowning:

Same here.

- Michael Spencer

Cheers,
Rafael

Hi,

I think it's an awesome idea to make sure all names are logical. It is
an essential feature of a good API to have logical naming :slight_smile:

I really dislike that all the files and classes in the MC library
start with MC. This is c++, not c :frowning:

On a similar note, all the classes in clang/CodeGen are prefixed with
CG or even CodeGen, could those be renamed as well?

And speaking of the clang codegenerator, I as a llvm newbie was
confused by the ModuleBuilder.h/.cpp. These files actually contain the
definition of the CodeGenerator itself that I was searching for (being
sort of the entry point of the codegenerator).

I think it would be more clear if they were called
CodeGenerator.h/.cpp. Or perhaps even splitted out into
CodeGenerator.h and IR/CodeGenerator.h/.cpp.

Kind regards,
Tinco