On Thu, Nov 22, 2012 at 6:02 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <<a href="mailto:geek4civic@gmail.com">geek4civic@gmail.com</a>> wrote:<br>
> 2012/11/22 Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>>:<br>
>> Hello LLVM & Clang hackers!<br>
>><br>
>> Based on a discussion with Chris, I would like to propose a Great<br>
>> Renaming of Things for the 3.3-era LLVM and Clang codebase.<br>
>><br>
>> First and foremost, the two most significant changes I would like to make:<br>
>><br>
>> 1) llvm/lib/VMCore/... -> llvm/lib/IR/...<br>
>><br>
>> I've discussed potential names for the VMCore (or LLVMCore) library<br>
>> with lots of folks, and the best idea anyone has was Chris's initial<br>
>> suggestion: IR. So I'd like to minimize the bikeshed discussions on<br>
>> this one. ;]<br>
><br>
> Oh I missed the discussion. I prefer "Core." Yes, bikeshed.<br>
<br>
</div>I dislike 'Core' and all other overly generic names. Specifically, why<br>
is Support not Core? Or vice versa? I would like a name that actually<br>
represents the principle organizing component, and that component in<br>
this case is the C++ APIs making up the IR of the compiler.<br>
<div class="im"><br>
<br>
>> There is one interesting question here: should we move<br>
>> include/llvm/*.h to include/llvm/IR/*.h to match other libraries?<br>
><br>
> IMHO, we may keep include/llvm/*. They should be essential interfaces.<br>
<br>
</div>I dislike the inconsistency of the include tree and the lib tree. When<br>
that inconsistency is just collapsing an entire directory to a single<br>
file, it seems fine and even good when the names align. But this seems<br>
somewhat less principled than that.<br>
<br>
Essentially, consistency is a strong argument. I'm looking for strong<br>
arguments for keeping them where they are to counter that.<br></blockquote><div><br></div><div>+1 for moving the IR headers into their own sub-directory.  This was (is) definitely messing with my OCD!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
<br>
> s/AsmParser/IRASM/ (to be distinguished against MCASM)<br>
<br>
</div>This is a really good one.<br>
<br>
I would paint this bikeshed LLParser or IRParser. "Asm" has to go though.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>
</div>