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" <[email protected]>
>
> What about having a __speed macro:
>
> int very_frequently_user_func() __speed {
> ...
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
