search for: bikesh

...t 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. > 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 i...

...o 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 organ...

...ost, 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. ;] There is one interesting question here: should we move include/llvm/*.h to include/llvm/IR/*.h to match other libraries? 2) clang/lib/CodeGen/... -> clang/lib/IRGen/... I think this name is so painfully obvious that everyone will be happy with this change... .....

...enamings 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 bikeshed left is the name for the CodeGen classes, and I'll mostly defer to John's whims there as he has to read and touch that code more than most others. =] On Thu, Nov 22, 2012 at 12:56 AM, Chandler Carruth <chandlerc at google.com> wrote: > Hello LLVM & Clang hackers! > > B...

...>> 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 &g...

...s, 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/... (-1 karma to self for participating in bikeshed) I'm not sure how and if this change would affect my group, but I'd have a slight preference to llvm/lib/LLVMIR/ ----------- While the current naming may not be the best I'm -1 for the change in general.

...tting issue? If something is already the overwhelmingly > common style (& it's not a case where it used to be the style, the > style has been updated, and nothing has been migrated yet) then just > make clang-format agree with reality - this doesn't require a > discussion or bikeshed. > It's not overwhelming, but the preponderance seems to be towards putting it on its own line (the exceptions are usually small trait specializations like isPodLike). I give some rough numbers here < http://thread.gmane.org/gmane.comp.compilers.llvm.devel/63378> (and see Daniel'...

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 ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents ExecutionEngine/RuntimeDyld -> JIT/RuntimeDyld (maybe...

...ake: > > 1) llvm/lib/VMCore/... -> llvm/lib/IR/... I strongly support this. > > 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. ;] > > There is one interesting question here: should we move > include/llvm/*.h to include/llvm/IR/*.h to match other libraries? Yes. Very much so. There should be no headers in include/llvm/. > > > 2) clang/lib/CodeGen/... -> clang/lib/IRGen/...

...something is already the overwhelmingly >> common style (& it's not a case where it used to be the style, the >> style has been updated, and nothing has been migrated yet) then just >> make clang-format agree with reality - this doesn't require a >> discussion or bikeshed. > > > It's not overwhelming, but the preponderance seems to be towards putting it > on its own line (the exceptions are usually small trait specializations like > isPodLike). I give some rough numbers here > <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/63378&...

...> 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/... > > (-1 karma to self for participating in bikeshed) > > I'm not sure how and if this change would affect my group, but I'd have a > slight preference to llvm/lib/LLVMIR/ I'm pretty opposed to repeating LLVM in the name of any directory... There's absolutely no ambiguity here. > While the current naming may not be the...

...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 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 > ExecutionEngine/IntelJITEvenst -> JIT/IntelJITEvents > ExecutionEngi...

...espect to this formatting issue? If something is already the overwhelmingly common style (& it's not a case where it used to be the style, the style has been updated, and nothing has been migrated yet) then just make clang-format agree with reality - this doesn't require a discussion or bikeshed.

...gly >> >> common style (& it's not a case where it used to be the style, the >> >> style has been updated, and nothing has been migrated yet) then just >> >> make clang-format agree with reality - this doesn't require a >> >> discussion or bikeshed. >> > >> > >> > It's not overwhelming, but the preponderance seems to be towards putting >> > it >> > on its own line (the exceptions are usually small trait specializations >> > like >> > isPodLike). I give some rough numbers her...

> 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

> Are there other names that are poor choices and are lingering in our > codebases? I'm willing to sign up to do more renames while I'm at > this, so this is a chance to get someone else to do the heavy lifting. > =] Class names too, not just file/directory names? I've been trolling through the integrated assembler lately, and had a real "can't tell the players

...the overwhelmingly > >> common style (& it's not a case where it used to be the style, the > >> style has been updated, and nothing has been migrated yet) then just > >> make clang-format agree with reality - this doesn't require a > >> discussion or bikeshed. > > > > > > It's not overwhelming, but the preponderance seems to be towards putting > it > > on its own line (the exceptions are usually small trait specializations > like > > isPodLike). I give some rough numbers here > > <http://thread.gmane.or...

...t; }; > > > > I'm guessing any compiler that decides to waste memory in this way > > will quickly get dropped by users and then we won't worry > > about building QEMU with it. > > There are other responses in the thread here and I don't really care to > bikeshed on this issue. Great. Let's make the bikeshed blue then? > >> Well, given that virtio is widely deployed today, I would think the 1.0 > >> standard should strictly reflect what's deployed today, no? > >> Any new config layout would be 2.0 material, right? >...