> For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > to zero. Inlining at -Os should already only happen if it decreases > (overall!) code-size. Thus, inlining a function that is called once and > that does not need to be emitted will always be an overall code-size > win. > > > A side question... Are 'static' single call-site functions always > > inlined? I would hope not (under -Os), but just checking. > > Yes. This is always a code-size win.
Should be, but in practice isn't. On Thumb-2 we found that the overhead of a function call was often smaller than the cost of lengthening branches in the caller. It turns out that, over a fair selection of applications, programmers tend to write "nice" sized functions. After inlining we have big nasty blocks of code that exceed the range of a short branch instruction. Of course a sufficiently smart reordering pass should be able to fix this by out-of-lining the big block of code. I'm pretty sure gcc can't currently do this. Paul