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

[Chris Lattner]

On Nov 22, 2012, at 3:02 AM, Chandler Carruth <chandlerc at google.com> wrote:
>>> 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 :)

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