On Mon, Jan 26, 2009 at 5:41 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Mon, Jan 26, 2009 at 5:29 PM, Hariharan <harihar...@picochip.com> wrote: >> Hi, >> I ran into some code-size/stack size bloat using -Os for a piece of code. >> This seemed to happen only when certain single call-site functions are >> defined "static" and not otherwise. On investigating further on this, i see >> that the inline_functions_called_once seems to rely only on >> "cgraph_check_inline_limits", whereas other inlining code go through more >> rigorous cost-benefit analysis to decide on inlining (especially with >> INLINE_SIZE). >> >> I have been looking at re-setting some of the parameters used in >> "cgraph_check_inline_limits" for inlining for picochip. I could not >> understand the way PARAM_LARGE_FUNCTION_GROWTH and PARAM_STACK_FRAME_GROWTH >> are used in this function. Both of these parameters are used as a fraction >> of the bigger (or to) function. >> >> I want to be able to say, if the inlining would increase the code size or >> stack frame size, dont inline. Otherwise, go ahead an inline. Of course, i >> am compiling this code at -Os, so this condition is probably obvious. Can >> you advice me on how to use these parameters to do that? > > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > to zero.
Oh, and LARGE_STACK_FRAME to zero as well, for result stack frame sizes below LARGE_STACK_FRAME the growth limit is not applied. > 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. > > Richard. > >> Thanks >> Hari >> >> PS: If this were to be considered a "bug", i will file a report with a >> testcase. >> >> >
