12

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.

Improve this question
7
  • Just curious, what happens if you invert the if statement? Commented Mar 29, 2011 at 19:17
  • Either way, gcc puts the function prologue/epilogue (saving registers, adjusting stack alignment, etc.) outside of both cases, so the cost is incurred on both. Commented Mar 29, 2011 at 19:23
  • Your samples lack any of the complicating bits. Are you suggesting that the compiler messes it up even with empty else blocks? Commented Mar 29, 2011 at 19:35
  • OK, add printf("hello, world\n"); to the empty blocks... Seriously it doesn't matter much what's there. If it makes one or more function calls, you'll incur stack alignment prologue, and if it uses a non-trivial amount of registers, you'll incur saving/restoring one or more of ebx/esi/edi/ebp. Commented Mar 29, 2011 at 19:46
  • Also note: I've tried __builtin_expect and it makes no difference. Commented Mar 29, 2011 at 19:47

5 Answers 5

Reset to default
2

Update

To explicitely suppress inlining for a single function in gcc, use:

void foo() __attribute__ ((noinline)) { ... }

See also How can I tell gcc not to inline a function?

Functions like this will regularly be inlined automatically unless compiled -O0 (disable optimization).

In C++ you can hint the compiler using the inline keyword

If the compiler won't take your hint you are probably using too many registers/branches inside the function. The situation is almost certainly resolved by extracting the 'complicated' block into it's own function.

Update i noticed you added the fact that they are extern symbols. (Please update the question with that crucial info). Well, in a sense, with external functions, all bets are off. I cannot really believe that gcc will by definition inline all of a complex function into a tiny caller simply because it is only called from there. Perhaps you can give some sample code that demonstrates the behaviour and we can find the proper optimization flags to remedy that?

Also, is this C or C++? In C++ I know it is common place to include the trivial decision functions inline (mostly as members defined in the class declaration). This won't give a linkage conflict like with simple (extern) C functions.

Also you can have template functions defined that will inline perfectly in all compilation modules without resulting in link conflicts.

I hope you are using C++ because it will give you a ton of options here.

Improve this answer
Sign up to request clarification or add additional context in comments.

10 Comments

No they won't, because of the complex part.
And because they're external.
Also note that even if I move the 'complicated' branch into its own function, (1) gcc will move it right back because gcc inlines functions that are only called from one place, and (2) even if gcc didn't move it back, setting up for a function call is one of the causes of the ugly prologue code that's making the trivial case slow, and gcc won't put the setup just in one of the branches.
@R.. you're not really encouraging us to help you and think along. Please provide sample code so we can do actual analysis instead of just doing a 'I think'/'I suppose'/'Nah it would just' show. I'm starting to think you are really venting an opinion instead of asking a question
PS. I noticed only now that you mention the function being external. That is a pain. Updating my answer
|
2

I would do it like this:

static void complex_function() {} void foo() { if(simple_case) { // do whatever return; } else { complex_function(); } }

The compiler my insist on inlining complex_function(), in which case you can use the noinline attribute on it.

Improve this answer

Comments

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.

Improve this answer

9 Comments

@Jens: Thanks for the idea, but inlining is not an option. This is an extern function in a library, and having half of it inlined in the caller would create a nasty implementation/version dependency in the caller.
@R.. In any case, inline or not it seems that the newer versions of gcc can thus split of a part of a function that is costly. Maybe by looking into the recent optimization improvements of gcc you'd find something useful.
Is there a particular option I should look at?
That ("hot path" splitting) looks like the general type of optimization I need, but for use when not inlining. I wonder if gcc can apply it to functions that are not candidates for inlining. I might get 4.6 and try playing with it... but my guess is we'll have to wait for 4.7 or 4.8 before this functionality is useful to the case I described... :-(
@R.., you could always compile just one function per compilation unit. Tell the compiler to inline just that function in that unit but force the generation of the symbol, there. If your header files only contain prototypes and no definitions the compiler simply can't inline for real. My guess would be that gcc would construct the function with the "hot path" feature, thus splitting it in two.
|
0

I would probably refactor the code to encourage inlining of the simple case. That said, you can use -finline-limit to make gcc consider inlining larger functions, or -fomit-frame-pointer -fno-exceptions to minimize the stack frame. (Note that the latter may break debugging and cause C++ exceptions to misbehave badly.)

Probably you won't be able to get much from tweaking compiler options, though, and will have to refactor.

Improve this answer

16 Comments

Wow, I've had a lot of answers suggesting to do things to get gcc to inline better, when the question states that this an external function and inlining is not possible...
The inlining I'm talking about is, in the case of externals, wrapper functions or even macros. Catch the simple case(s) inline and invoke the external for the rest. This does involve testing the condition twice, but only int he case that's expensive anyway so it's down in the noise. This isn't rocket science.
Again, this isn't possible in library code, unless you want to write one of those libraries where every single version is incompatible because all the internals of supposedly-opaque library structures got inlined into the calling application. If gcc weren't messing up the simple cases, my external functions would be 80-90% as good as macros or inline functions, but instead they're only 50-70% as good, because gcc is adding lots of unnecessary overhead.
You are busily building a contradiction here. If it's possible to change the function linkage then it's possible to interpose a macro. If you can't interpose a macro then it's too late to change the function linkage.
I'm not trying to use macros or inline functions, at all. I'm trying to write a normal extern-linkage function in a library that has a short, fast "hot path" (thanks to Jens for the word) with minimal entry/exit overhead and a much larger branch that's executed only once or rarely.
|
0

Seeing as these are external calls, it might be possible the gcc is treating them as unsafe and preserving registers for the function call(hard to know without seeing the registers that it preserves, including the ones you say 'aren't used'). Out of curiousity, does this excessive register spilling still occur with all optimizations disabled?

Improve this answer

5 Comments

On x86 ABI, ebx, ebp, esi, and edi are required to be saved by the callee if it clobbers them. This is correct. The problem is that gcc unconditionally does all the work of saving and restoring them at function entry and exit, even when the simple case never clobbers them. If it moved the saving and restoring inside the complex branch, the simple branch would be half (or fewer) as many instructions and significantly faster.
@R..: You can tweak that behavior a bit but there isn't much fine grained control — and if these functions are extern and not under your control, how do you know there are unused registers?
@geekosaur: This question has nothing to do with code generation for the caller, which of course cannot know what registers the callee uses. This whole topic is about code generation for the callee, which absolutely knows what registers it uses.
No, it only absolutely knows if you write it in assembler or you insist on a particular compiler version and optimization level so that you know with certainty the generated code. In any case, I'm done with this question; you're clearly stuck in a world view in which the only possible answer is "you can't".
And you're clearly only interested in giving me "advice" along the lines of "throw other much-more-important considerations out the window and do what I say" rather than trying to answer the question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.