Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers
[Posted January 3, 2006 by corbet]
| From: |
| Andrew Morton <akpm-AT-osdl.org> |
| To: |
| Ingo Molnar <mingo-AT-elte.hu> |
| Subject: |
| Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers |
| Date: |
| Wed, 28 Dec 2005 20:11:50 -0800 |
| Cc: |
| torvalds-AT-osdl.org, arjan-AT-infradead.org,
linux-kernel-AT-vger.kernel.org, mpm-AT-selenic.com |
| Archive-link: |
| Article,
Thread
|
Ingo Molnar <mingo@elte.hu> wrote:
>
> I think gcc should arguably not be forced to inline things when doing
> -Os, and it's also expected to mess up much less than when optimizing
> for speed. So maybe forced inlining should be dependent on
> !CONFIG_CC_OPTIMIZE_FOR_SIZE?
When it comes to inlining I just don't trust gcc as far as I can spit it.
We're putting the kernel at the mercy of future random brainfarts and bugs
from the gcc guys. It would be better and safer IMO to continue to force
`inline' to have strict and sane semamtics, and to simply be vigilant about
our use of it.
IOW: I'd prefer that we be the ones who specify which functions are going
to be inlined and which ones are not.
If no-forced-inlining makes the kernel smaller then we probably have (yet
more) incorrect inlining. We should hunt those down and fix them. We did
quite a lot of this in 2.5.x/2.6.early. Didn't someone have a script which
would identify which functions are a candidate for uninlining?
(
Log in to post comments)