This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: New attribute "infrequent"?


> > Date: Mon, 27 Aug 2001 18:47:06 +0200
> > From: Jan Hubicka <jh@suse.cz>
> > To: Ulrich Drepper <drepper@cygnus.com>
> 
> > Actually for enabling -Os, the attribute "infrequent" looks like
> > better choice to me:
> 
> If 80% of the code is executed 10% of the time, does it make any sense
> to have people mark up the 80% of the code as infrequent?  Or put
> another way, would it not make more sense to have the mark the
> frequent code instead?
> 
> Just wanna make sure we solve the right problem...
As I've mentioned originally, I was shooting mainly for usage in the standard
headers - like libc.  I can imagine to mark function as perror, exception
delivery code, startup code (where cost for loading it exceeds the runtime
perofmrance) as infrequent.  These function are smaller portion of glibc (to my guess),
but they are important part of static overhead - they are executed at each startup
and if you link programs statically, actually majority

In applications, it may make sense to have reversed attribute and use -Os
optimization by default, but it is completely different from current practice.
While currently programmes don't need to mark everything and their programs get
usually fast (but huge), doing reverse would require the assistance as the
programs will get usually slow (and small).
I would not rely on programmers to guess this, instead I would preffer to have
profile driven optimizations more commonly used.

For instance should be "strlen" optimized for size? 99% of programs most
probably don't contain it in perofmrance cirtical sections, but still there
is 1% that do and current practice is to optimize it for speed.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]