Re: [RFC] Observations on x86 process.c

[<cutaway@bellsouth.net>]

This is a good idea BTW.

It could be expanded upon further by adding something else to designate
error case and infrequent oddball situation code blocks.  Even "fast"
functions often include large sections of stuff that doesn't need speed
optimizations.  That stuff just winds up puffing up the L1/L2 when bits of
it get touched.  A compiler smart enough to emit function code to two
different .text regions could take advantage of this.

ex.

int __fast fast1(whatever...)
{
    if (rare_case) {
    ...large blob of non-speed critical code...
    }
    ...fast code...
}

int __fast fast2(whatever...)

The way it happens today is GCC (usually) relocates the blob of speed
insensitive code towards the bottom of the function, which means you're less
likely to pick up a bit of fast2()'s prolog as you're exiting fast1, and
more likely to pollute the caches with worthless stuff.

If blocks can be designated as infrequent/error paths and relocatable to a
different .text section you stand a much better chance of picking up
something useful as functions exit.  ex:

int __fast fast1(whatever...)
{
    if (rare_case) __attribute__((slowcode)) {
    ...large blob of non-speed critical code...
    }
    ...fast code...
}

Where __attribute__((slowcode)) is defined in some macro.


----- Original Message ----- 
From: "Denis Vlasenko" <vda@ilport.com.ua>
>
> What about having a __speed macro:
>
> int very_frequently_user_func() __speed {
> ...
> }