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

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

Hi,

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

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

On Nov 22, 2012, at 8:00 AM, Chris Lattner <clattner at apple.com> wrote:
>>>> 
>>>> 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).
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

On Thu, Nov 22, 2012 at 6: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.
>
+1 for moving the IR headers into their own sub-directory.  This was (is)
definitely messing with my OCD!

>
>
> > 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121122/ff76bea5/attachment.html>

2012/11/23 Chris Lattner <clattner at apple.com>:
> 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 :)
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

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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev