This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inline limits
On Mon, Jan 26, 2009 at 5:41 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Mon, Jan 26, 2009 at 5:29 PM, Hariharan <hariharans@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.
>>
>>
>