[LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)
Chris Lattner
clattner at apple.com
Thu Nov 22 08:00:18 PST 2012
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
More information about the llvm-dev
mailing list