search for: ll_naming

...to avoid header pollution, since it's > only on one enum... ;) > > Yeah, I remember that conversation - I just didn't know that any action had been taken. However, my other concern is this: According to the LLVM Coding Standards document (http://llvm.org/docs/CodingStandards.html#ll_naming): *Function names* should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()). The coding standards say functions should begin with a lower case letter, but I...

...nd enum" rule to > > http://codereview.appspot.com/3402041 > > and attached it to this message too. Would you please take a look? Thanks, Applied, thanks! After applying it, I went through and restructured the section for readability: http://llvm.org/docs/CodingStandards.html#ll_naming -Chris > > On Wed, Dec 1, 2010 at 9:19 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: >> Thanks, Chris and John. Committed in r120689. I'll try to add the >> *Kind rule in a separate patch. Cheers, >> >> On Wed, Dec 1, 2010 at 5:18 PM, Chris Latt...

Hi, I uploaded a patch for the "*Kind enum" rule to http://codereview.appspot.com/3402041 and attached it to this message too. Would you please take a look? Thanks, On Wed, Dec 1, 2010 at 9:19 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > Thanks, Chris and John.  Committed in r120689.  I'll try to add the > *Kind rule in a separate patch.  Cheers, > >

On 18 February 2011 21:34, Talin <viridia at gmail.com> wrote: > Sorry, I meant DIBuilder. DIBuilder is the new DIFactory. I've been playing with it this week and it's much easier and straightforward to use. I'm still having problems to create arrays, though. As far as I remember (from the 2010 meeting), the idea was to replace and deprecate DIFactory. I'm not saying we

Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at

...lue *, Value *>::iterator> vp_iterator_pair; > + typedef std::pair<std::multimap<value_pair, value_pair>::iterator, > + 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,...

...tor> vp_iterator_pair; > > + typedef std::pair<std::multimap<value_pair, value_pair>::iterator, > > + 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<Va...

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