lkml.org 
[lkml]   [2008]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] x86: phase out forced inlining
On Tue, 4 Mar 2008 08:32:48 +0100 Ingo Molnar <mingo@elte.hu> wrote:

>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > urgh. This will cause whatever problem
> > 4507a6a59cfc6997e532cd812a8bd244181e6205 fixed five years ago to
> > resurface for incautious gcc-3.x users.
>
> hm, commit 4507a6a59cfc6997e532cd812a8bd244181e6205 does not exist:
>
> fatal: bad object 4507a6a59cfc6997e532cd812a8bd244181e6205

This was 2.5.x - you'll need to look in the historical-git tree.

Here it is:



: commit 4507a6a59cfc6997e532cd812a8bd244181e6205
: Author: akpm <akpm>
: Date: Tue Mar 11 07:42:00 2003 +0000
:
: [PATCH] work around gcc-3.x inlining bugs
:
: Force inlining even when gcc-3.x is too confused to do it for us.
:
: BKrev: 3e6d9348GA9aKzeN-bjzQzMMt85t8g
:
: diff --git a/include/linux/compiler.h b/include/linux/compiler.h
: index e92f472..a28d0d5 100644
: --- a/include/linux/compiler.h
: +++ b/include/linux/compiler.h
: @@ -1,6 +1,12 @@
: #ifndef __LINUX_COMPILER_H
: #define __LINUX_COMPILER_H
:
: +#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
: +#define inline __inline__ __attribute__((always_inline))
: +#define __inline__ __inline__ __attribute__((always_inline))
: +#define __inline __inline__ __attribute__((always_inline))
: +#endif
: +
: /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
: a mechanism by which the user can annotate likely branch directions and
: expect the blocks to be reordered appropriately. Define __builtin_expect
:

I was very bad about changelogging that one. I do remember there was a bit
of to-and-fro before we decided to do it this way. Some googling would be
needed.

> but i suspect it must be something along the lines of the known problem
> of really old gcc versions creating huge stackframes?

iirc gcc was failing to inline functions which we'd marked `inline' and it
was generating poorer code as a result. It might also have been generating
an out-of-line copy for each compilation unit which called the inline (it
would have to do this?)

> Those pristine gcc
> versions were practically unusable for distro kernels anyway (and were
> patched by distros) - but i have no problem with restricting this
> feature to gcc4x. gcc4x creates more compact -Os code too, so it's
> recommended for smaller image sizes.

yup.



\
 
 \ /
  Last update: 2008-03-04 09:05    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site