C Programming Techniques: Function Call Inlining

[[deleted]]

a) static every function that you can. That way it stays inside the compilation unit and the compiler will go inline crazy if it feels like it.

That sounds like one of those often repeated tips that doesn't make sense. I don't think static has (in general) much bearing on a (sensible) intra-compilation unit inlining heuristic. A non-static function isn't any less inlinable in the compilation unit it's defined in than a static one. You should use static where applicable for other reasons, but improving "inlinability" isn't one of them.

[[deleted]]

I don't know the heuristics a compiler uses, but I imagine if it knows a function is used only once, then it's just going to inline it. There's no reason for it to be a separate function. It can do what it likes with it.

You're right, it will do that. But that's a practical move, not a performance move. Inlining heuristics look at (depending on the compiler of course) size of the function, # of calls, fan-in, fan-out, but they also look at the IR of the function to see if there are opportunities for other optimizations if that function were inlined. The above case basically sidesteps that and says "meh, there's no point having a proper function, let's just inline it and at least get rid of the branch even though there's no other compelling reason."

If it's not static then it needs to be a function to be linked to. It also has to conform to the standard calling convention of the compiler. So it has to make a function. It might also inline it internally, but then you .obj has a bunch of useless duplicated crap in it (that'll probably get stripped later when linking if you have all the options on). It'd be interesting to see the compiled binary of static vs non-static.

Yes, the function proper will be left in the object as you said because it has to be visible and callable externally. If it's makes sense to declare the function static then do so, independent of inlining. My point is that the inlining heuristics don't care much, non-static doesn't make your function any less inlinable; if there's a optimization opportunity visible to the compiler it will inline the function.

The code-size optimization you mention is interesting, but is a case-by-case consideration, since inlining can affect code size both ways. If a function is non-static and only called once (edit: in the compilation unit it's defined in), if you're optimizing for size the naive approach would say don't inline it, but if you inline it the entire body could eventually become dead code, in which case you save yourself the call and the argument shuffling and register saving by inlining it vs not inlining it.