On Thu, 5 Feb 2009, Paul Brook wrote: > > 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.
Hmm, we should be able to model this counting the number of edges bypassing the call, right? Richard.
