search for: textfilereader

...variable names start with a lowercase letter. Index: CodingStandards.rst =================================================================== --- CodingStandards.rst (revision 219065) +++ CodingStandards.rst (working copy) @@ -1073,8 +1073,8 @@ nouns and start with an upper-case letter (e.g. ``TextFileReader``). * **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``). + be camel case, and start with a lower case letter (e.g. ``leader`` or + ``boats``). * **Function names** should b...

...t;> wrote: >> > Sorry, this seems to have not followed the thread, but here was my >> > comment: >> > >> > http://codereview.appspot.com/3264041/diff/1/docs/CodingStandards.html#newcode801 >> > docs/CodingStandards.html:801: camel case (e.g. <tt>TextFileReader</tt> >> > and <tt>isLValue</tt>). >> > I would really prefer some stylistic difference between variables and >> > types/functions. This is mostly a problem (for me) with local variables, >> > where having some signifier of the locality helps me...

...neInstr *MI" vs "mi". It also means far less churn when someone decides to go crazy fixing the codebase. :) Given that, here are some suggestions for a future rev of your patch: +<p>In general, names of types, functions, and variables should be in +camel case (e.g. <tt>TextFileReader</tt> and <tt>isLValue</tt>). I'd suggest using <tt>isLValue()</tt> to make it clear that one is a type and one is a function. +Function names should be verb phrases I completely agree, but it is worth adding a short justification, explaining that methods are &qu...

On Sun, Nov 28, 2010 at 11:02 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> I enjoyed the new coding style in recent patches. Camel case makes it easy >> to pick a descriptive name. Starting functions and variables with lower >> cases reduces chances to conflict with a type name. > Honestly speaking, I don't. Especially in the cases when varname is

...gt; Index: CodingStandards.rst >> =================================================================== >> --- CodingStandards.rst (revision 219065) >> +++ CodingStandards.rst (working copy) >> @@ -1073,8 +1073,8 @@ >> nouns and start with an upper-case letter (e.g. ``TextFileReader``). >> >> * **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``). >> + be camel case, and start with a lower case letter (e.g. ``leader``...

...> + std::multimap<value_pair, value_pair>::iterator> > + vpp_iterator_pair; http://llvm.org/docs/CodingStandards.html#ll_naming "Type names (including classes, structs, enums, typedefs, etc) should be nouns and start with an upper-case letter (e.g. TextFileReader)." > + void getCandPairs(unsigned vBits, BasicBlock&BB, > + std::multimap<Value *, Value *> &candPairs, > + std::vector<Value *> &pairableInsts); "Variable names should be nouns (as they represent state)....

...map<value_pair, value_pair>::iterator> > > + vpp_iterator_pair; > > http://llvm.org/docs/CodingStandards.html#ll_naming > > "Type names (including classes, structs, enums, typedefs, etc) should be > nouns and start with an upper-case letter (e.g. TextFileReader)." > > > > + void getCandPairs(unsigned vBits, BasicBlock&BB, > > + std::multimap<Value *, Value *> &candPairs, > > + std::vector<Value *> &pairableInsts); > > "Variable names should...

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

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