> 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. > > I'm willing to believe it can also lead to higher register > pressure. (weasel words for "I haven't checked and I can think > of reasons both why it could, and why it should not")
So far I didn't see testcases where inlining would make things slower by register pressure issues alone. There are testcases where inlining causes more TER that leads to register pressure but those are more or less problems elsewhere and seem to be quite rare and thus I would be inclined to claim that the optimization is win in general. There is flag controlling inlining functions called once, so perhaps we can do some testing on CSiBE and thumb or other embedded targets and set it per (sub)target basis? I did CSiBE testing on i386 at the time we was enabling inlining functions called once by deafault at -O2 and -Os and it was code size win. Perhaps even more little luck can be done by fine-tunning large-function and large-function-gorowth parameters so the inliner usually don't make functions to grow over the size of branch instructions, but it would be iffy since code size estimates at inlining time are very rough. I seem to recall at least one paper on branch reordering describing algorithm for code size only, this would be probably good to have, since the trace cache algorithm is very poor on estimating code size benefits. Honza > > brgds, H-P
