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

Hi Jim, Thanks for reviewing the patch. I couldn't get rid of STLExtras.h, but other than that, I followed all the suggestions in your email. Please let me know if you notice anything else that needs fixing. On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Akira, > > This is looking good. Some specific comments on the details below. > >

Hi Akira, Just two very minor things that I missed the first time around. 1. The 'fixup" member of ELFRelocation entry should be "Fixup" instead. 2. Since we're always passing in a non-NULL fixup, that should probably be a reference, not a pointer. Good for commit with those tweaks. Thanks! -Jim On Mar 23, 2012, at 1:07 PM, Akira Hatanaka wrote: > Hi Jim, >

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

> I really dislike that all the files and classes in the MC library > start with MC. This is c++, not c :( Same here. > > - Michael Spencer Cheers, Rafael

I think this endeavour is good. My request is that there be some words about whatever standard you come up with, probably in the coding standards documentation or at least a link from the coding standards to the file bike shed painting conventions. Don't make this an insider's rule. It is tiresome to have one's commit rejected due to undocumented preferences of the reviewer. Also,

Hi, I think it's an awesome idea to make sure all names are logical. It is an essential feature of a good API to have logical naming :) > I really dislike that all the files and classes in the MC library > start with MC. This is c++, not c :( On a similar note, all the classes in clang/CodeGen are prefixed with CG or even CodeGen, could those be renamed as well? And speaking of the

On Thu, Nov 22, 2012 at 12:56 AM, Chandler Carruth <chandlerc at google.com> wrote: > 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/... ->

On Thu, Nov 22, 2012 at 2:49 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: > On 11/22/12 04:53 PM, NAKAMURA Takumi 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

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat

Lacking any dissenting opinions, I wanted to give a heads up to folks: I plan to do the two major renamings I mentioned above this weekend. I'll do it over the weekend to try to minimize the number of patches that folks have outstanding touching files in those trees. I'll respond later this week with more details to help sort out any last questions of naming. It looks like the only real

On 11/22/12 04:53 PM, NAKAMURA Takumi 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:

On 11/22/2012 12:07 PM, Chandler Carruth wrote: >> While the current naming may not be the best I'm -1 for the change in >> > general. > Are there any serious reasons or concerns? I'm well aware that this > will impose a cost on out-of-tree projects, but on the whole it should > be pretty minimal and consist of some applications of 'sed'. Well, it's a

Hi there. What about repainting the top-level bike-shed - the build system itself? I've got a framework called "v3c" in SourceForge that has a top-level makefile. From that makefile you can just do "make" to build it with debug information, "make release" for a release build, "make -j7 distcheck" to throw a few cores at the build, "make -j7 git

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

On Nov 24, 2012, at 1:02 AM, Tinco Andringa <mail at tinco.nl> wrote: > Hi, > > I think it's an awesome idea to make sure all names are logical. It is > an essential feature of a good API to have logical naming :) > >> I really dislike that all the files and classes in the MC library >> start with MC. This is c++, not c :( > > On a similar note, all

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

Hi Akira, If I follow correctly, the relocation entries can thus be in a different order than the instructions that they're for? That seems a bit odd, but I suppose there's nothing inherently wrong with that. It's just not something, AFAIK, that llvm has had to deal with before. This should definitely be a target-specific thing, not a general ELFObjectWriter thing, as other targets

Catching up on post-holiday emails. I may have comments on the more general stuff later, but wanted to respond to this bit more quickly. On Nov 22, 2012, at 3:05 AM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: >> s/ExecutionEngine/EE/ (or something like buzzword!) > > I don't

On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > s/ExecutionEngine/EE/ (or something like buzzword!) I don't really know the best bikeshed color here. Jim? My lame idea would be: ExecutionEngine -> JIT ExecutionEngine -> JIT/Legacy ExecutionEngine/MCJIT -> JIT/MC ExecutionEngine/OProfileJIT -> JIT/OProfile