lkml.org 
[lkml]   [2005]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch 00/2] improve .text size on gcc 4.0 and newer compilers
    From
    Date
    On Mer, 2005-12-28 at 20:11 -0800, Andrew Morton wrote:
    > 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?

    There is a tool that does this quite well. Its called "gcc" ;)

    More seriously we need to seperate "things Andrew thinks are good inline
    candidates" and "things that *must* be inlined". That allows 'build for
    size' to do the equivalent of "-Dplease_inline" and the other build to
    do "-Dplease_inline=inline". Gcc's inliner isn't aware of things cross
    module so isn't going to make all the decisions right, but will make the
    tedious local decisions.

    As far as bugs go - gcc -Os has also fixed bugs in the past. It doesn't
    introduce bugs so much as change them. Fedora means we have good long
    term data on -Os with modern gcc (not with old gcc but we just dumped <
    3.2 anyway).

    Nowdays the -Os code paths are also getting real hammering because many
    people build desktops, even OpenOffice with -Os and see overall
    performance gains for the system.

    Alan

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-12-30 16:29    [W:0.085 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site