Question

I’ve lately encountered a lot of functions where gcc generates really bad code on x86. They all fit a pattern of:

if (some_condition) {
    /* do something really simple and return */
} else {
    /* something complex that needs lots of registers */
}

Think of simple case as something so small that half or more of the work is spent pushing and popping registers that won’t be modified at all. If I were writing the asm by hand, I would save and restore the saved-across-calls registers inside the complex case, and avoid touching the stack pointer at all in the simple case.

Is there any way to get gcc to be a little bit smarter and do this itself? Preferably with command line options rather than ugly hacks in the source…

Edit: To make it concrete, here’s something very close to some of the functions I’m dealing with:

if (buf->pos < buf->end) {
    return *buf->pos++;
} else {
    /* fill buffer */
}

and another one:

if (!initialized) {
    /* complex initialization procedure */
}
return &initialized_object;

and another:

if (mutex->type == SIMPLE) {
    return atomic_swap(&mutex->lock, 1);
} else {
    /* deal with ownership, etc. */
}

Edit 2: I should have mentioned to begin with: these functions cannot be inlined. They have external linkage and they’re library code. Allowing them to be inlined in the application would result in all kinds of problems.

Answer 1

Perhaps upgrade your version of gcc? 4.6 has just been released. As far as I understand, it has the possibility of “partial inline”. That is, an easily integratable outer part of a function is inlined and the expensive part is transformed into a call. But I have to admit that I didn’t try it myself, yet.

Edit: The statement I was referring to from the ChangeLog:

Partial inlining is now supported and
enabled by default at -O2 and greater.
The feature can be controlled via
-fpartial-inlining.

Partial inlining splits functions with
short hot path to return. This allows
more aggressive inlining of the hot
path leading to better performance and
often to code size reductions (because
cold parts of functions are not
duplicated).

…

Inlining when optimizing for size
(either in cold regions of a program
or when compiling with -Os) was
improved to better handle C++ programs
with larger abstraction penalty,
leading to smaller and faster code.