This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inline limits
- From: Paul Brook <paul at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Richard Guenther <richard dot guenther at gmail dot com>, Hariharan <hariharans at picochip dot com>, rguenther at suse dot de, jh at suse dot cz
- Date: Thu, 5 Feb 2009 13:51:30 +0000
- Subject: Re: Inline limits
- References: <497DE4D3.2090104@picochip.com> <84fc9c000901260841q7325db58h49afd6b00489198b@mail.gmail.com>
> 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