similar to: [LLVMdev] RFC: variable names

On Mon, Oct 13, 2014 at 3:19 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Oct 13, 2014 at 3:04 PM, Nick Kledzik <kledzik at apple.com> wrote: > >> I’d like to discuss revising the LLVM coding conventions to change the >> naming of variables to start with a lowercase letter. >> > > Almost all of your negatives of the current conventions

> On Feb 2, 2019, at 8:18 PM, Chris Lattner <clattner at nondot.org> wrote: > > > >> On Feb 1, 2019, at 6:20 AM, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi all, >> >> As application of the naming rules are currently under discussion [1] this seems like a good time

Hi all, As application of the naming rules are currently under discussion [1] this seems like a good time to bring this up: The current variable naming rule [2] states: Variable names should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. Leader or Boats). I'm a relatively new arrival to the LLVM codebase and I want to follow the

Hi everyone, I have a code style question: should full test programs (.c,.cpp files) use the documented CamelCase from http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly or instead use lower_with_underscores as I've been told the .ll lit test files should use? I see both in existing files, and in particular for projects/compiler-rt I cannot

> On Jul. 5, 2018, at 18:12, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 5, 2018 at 5:30 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On Jul 5, 2018, at 1:09 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

I argue we should spell C++ lambdas (and other function-like variables) like functions, not like variables. - Use verbs, not nouns. - Use lowerCamelCase. Here's a patch that implements the change to the coding standards: https://reviews.llvm.org/D48991 <https://reviews.llvm.org/D48991> Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Dear all, Given the following vector: > (z <- c('R project', 'hello world', 'something Else')) [1] "R project" "hello world" "something Else" I know how to obtain all capitals or all lower case letters: > tolower(z) [1] "r project" "hello world" "something else" > toupper(z) [1] "R

Are there standard naming conventions in LLVM code? Most of the variable, member function, and member variable names seem to be camelcase, beginning with either lowercase or uppercase, or initialisms. But there are exceptions, e.g. some parts of classes dealing with iterators use an STL naming convention with underscores. Is this written down anywhere? Thanks, Cameron

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in

On Sun, Jan 20, 2013 at 8:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote: > > We're looking more at doing some serious hacking on LLD, and I'd like to > avoid doing lots of work in the codebase only to change the style around > later. > > > > My understanding was that LLD was always intended to

On 11/17/2011 12:38 AM, Hal Finkel wrote: > Tobias, et al., > > Attached is the my autovectorization pass. Very nice. Will you be at the developer summit? Maybe we could discuss the integration there? Here a first review of the source code. > diff --git a/docs/Passes.html b/docs/Passes.html > index 5c42f3f..076effa 100644 > --- a/docs/Passes.html > +++ b/docs/Passes.html

Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because

Hi Philip, I think you might be reading more into the suggestion/discussion than is actually there. * I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. Nobody suggested that. It’s perfectly possible to “be polite” and still not delay worthwhile work. * The current policy is "downstream is on their own". Nobody

On Jan 15, 2011, at 8:31 AM, Matthieu Monrocq wrote: > Hello Doug, > > *putting llvmdev in copy since they are concerned too* > > I've finally got around to finish a working implementation of the typical Levenshtein Distance with the diagonal optimization. > > I've tested it against the original llvm implementation and checked it on a set of ~18k by randomly

I have updated my patch based on Chris'es feedback. I removed the dbgout_calls macro, but left others in place for now. If there are no objections, I would like to commit this tomorrow evening (~7PM GMT-7). I have compiled and tested it on MSVC, with Michaels testing code and it looks good. Once this is committed, Michaels patch can be applied. -Nathan -------------- next part --------------

On Jan 20, 2013, at 10:18 PM, Chandler Carruth wrote: > Sorry, I wasn't trying to suggest anything vague, but rather refer to my previous (perhaps ill founded) understanding about the expected path forward for LLD. Anyways, I'll explain in a bit more detail so we can talk about the concrete issue. > > My concrete hope is that LLD migrates toward the coding standards that are

On Jan 19, 2013, at 1:55 AM, Chandler Carruth wrote: > We're looking more at doing some serious hacking on LLD, and I'd like to avoid doing lots of work in the codebase only to change the style around later. > > My understanding was that LLD was always intended to be a fully integrated LLVM project much like Clang, with a shared coding standard to go with the shared support

Hi Mehdi! I think the value to upstream (of doing mass reformatting in fewer commits) has to do with the intrusion of nonfunctional commits into `git blame` kinds of research. Every line that someone touches for a formatting reason necessarily obscures the history of functional changes in that block of code. The fewer of those that people have to work around, the better. I admit this is a

Hi, Can R read in .xyz files? If so, what is the package, thanks -- Shane [[alternative HTML version deleted]]

Greetings folks, We're looking more at doing some serious hacking on LLD, and I'd like to avoid doing lots of work in the codebase only to change the style around later. My understanding was that LLD was always intended to be a fully integrated LLVM project much like Clang, with a shared coding standard to go with the shared support libraries. Can we start that migration? I'm really