This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: New attribute "infrequent"?
- To: Ulrich Drepper <drepper at cygnus dot com>
- Subject: Re: New attribute "infrequent"?
- From: Jan Hubicka <jh at suse dot cz>
- Date: Mon, 27 Aug 2001 18:47:06 +0200
- Cc: Jan Hubicka <jh at suse dot cz>, gcc at gcc dot gnu dot org, pfk at fuchs dot offl dot uni-jena dot de, libc-alpha at sources dot redhat dot com, aj at suse dot de
- References: <20010827174751.G11402@atrey.karlin.mff.cuni.cz> <m3itf9h3e9.fsf@otr.mynet>
> Jan Hubicka <jh@suse.cz> writes:
>
> > Does this make sense? It would imply a lot of work on glibc side to tag all
> > functions...
> >
> > An extension can be allowing infrequent on variables too (such as stderr) and
> > predicting any block containing reference to such variable as infrequently
> > executing.
>
> If you go there (and it doesn't sound bad at all) please go one step
> further. Some compilers allow changing optimization levels and other
> code generation controlling variables in the source file. Something
> like
Actually for enabling -Os, the attribute "infrequent" looks like better choice
to me:
I don't think we want to control optimizations at smaller granuality (as it is
de facto uninmplementable), so function attribute looks better to me than
pragma in the code. For instance kernel folks already have initfunc functions
with several attributes, adding extra attribute to enable -Os is trivial.
Changing something else than -Ox to -Os is dificult to do - in general lots
of our code initializes costs and various settings on the startup of compiler.
(an yes, this partly affects -Os too. Sadly :()
Some parts are relativly expensive to initialize - as move_cost in regclass.c.
While it may make sense to switch those settings at compile time (for instance
to generate SSE enabled loop in program otherwise indepdendent on SSE) I
believe it is separate idea, relativly dificult to do and does not superset
this one.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> int
> foo (int a)
> {
> return a;
> }
>
> _Pragma ("-Os")
> int
> bar (int a)
> {
> return a;
> }
> _Pragma ("-Oprevious")
>
> int
> baz (int a)
> {
> return a;
> }
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Using __builtin_expect we can control the block ordering (though this
> should be improved on as well) but as you say, aggressive
In what way? I am just working in this area so it can be nice.
> optimizations shouldn't be carried out on code which isn't critical
> for the runtime.
>
> The _Pragma stuff above will in any case be needed for the C99-style
> control of floating-point handling.
Uhm yes...
Honza
>
> --
> ---------------. ,-. 1325 Chesapeake Terrace
> Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
> Red Hat `--' drepper at redhat.com `------------------------