This is the mail archive of the
mailing list for the GCC project.
Re: New attribute "infrequent"?
- To: mike stump <mrs at windriver dot com>
- Subject: Re: New attribute "infrequent"?
- From: Jan Hubicka <jh at suse dot cz>
- Date: Tue, 28 Aug 2001 14:41:55 +0200
- Cc: drepper at cygnus dot com, jh at suse dot cz, aj at suse dot de, gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com, pfk at fuchs dot offl dot uni-jena dot de
- References: <200108272027.NAA28045@kankakee.wrs.com>
> > Date: Mon, 27 Aug 2001 18:47:06 +0200
> > From: Jan Hubicka <email@example.com>
> > To: Ulrich Drepper <firstname.lastname@example.org>
> > 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.