[cfe-dev] [LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)
milseman at apple.com
Mon Nov 26 16:05:41 PST 2012
On Nov 22, 2012, at 3:02 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 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.
Note that in the current structure, "Asm" for IR means the textual representation while "Bitcode" represents the binary. Using "LL" for the textual helps to distinguish this, and the contents of lib/AsmParser's files already begin with "LL".
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the cfe-dev