Dimitrious I didn't realize you were working on this. Your patch is indeed very similar. :-)
Can I go ahead and rewrite mine following Richard's suggestions (which would make it even more similar to yours), and add your name to the ChangeLog entry too ? Thanks On 21 Jun 2011, at 13:20, Dimitrios Apostolou wrote: > FWIW I think that most of the speedup is due to inlining lookup_attribute(). > I got almost the same by applying only the attached very simple patch, since > strlen() was called too often (according to the profile at [1]). I used the > always_inline attribute to avoid using a macro. > > I was going to send it together with some other changes I'm trying and after > proper measurements. Anyway, better late than ever. Thanks to Christophe > Jaillet (CC'd) for pointing it to me. > > > Thanks, > Dimitris > > > [1] http://gcc.gnu.org/wiki/OptimisingGCC > > > > > On Tue, 21 Jun 2011, Richard Guenther wrote: > >> On Tue, Jun 21, 2011 at 12:17 PM, Nicola Pero >> <nicola.p...@meta-innovation.com> wrote: >>>>> This patch speeds up the C/C++/ObjC/ObjC++ compiler a little bit by >>>>> optimizing >>>>> lookup_attribute() and is_attribute_p(). The main change is that these >>>>> functions >>>>> are now inline. >>>> >>>> I don't think this is a good idea. >>> >>> Can you explain why ? You never do in your response :-) >>> >>> I'm guessing it's because you think the inline functions are too big and >>> that's >>> counter-productive ? >> >> Yes. >> >>>> For this case I'd factor out the NULL attribute list check into an >>>> inline function and keeping the non-NULL attribute list pieces out-of-line. >>> >>> Ok ... so is this what you'd like - the common, hot case in the inline >>> function, >>> and the less common, cold case in the out-of-line one ? :-) >> >> Right. >> >>> That makes sense - I'll try that out tonight (it takes a few hours to run >>> all >>> the benchmarks). ;-) >> >> Thanks. >> >>> >>>> Does it work for all languages? And yes, I agree it would be nice to >>>> canonicalize to the form without _s even in the attribute lists itself. >>>> Or go one step further - do not store an identifier but an enum as we >>>> in fact only ever insert known attributes into the list (which should >>>> be a VEC instead, possibly even sorted to allow binary search). >>> >>> Sure ... one step at a time. :-) >> >> Of course ;) >> >> Richard. >> >>> Thanks >>> >>> > <gcc-lookup_attr.patch>
