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    [W:0.023 / U:1.988 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site