lkml.org 
[lkml]   [2005]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

    * Andrew Morton <akpm@osdl.org> wrote:

    > 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.

    i think there's quite an attitude here - we are at the mercy of "gcc
    brainfarts" anyway, and users are at the mercy of "kernel brainfarts"
    just as much. Should users disable swapping and trash-talk it just
    because the Linux kernel used to have a poor VM? (And the gcc folks are
    certainly listening - it's not like they were unwilling to fix stuff,
    they simply had their own decade-old technological legacies that made
    certain seemingly random problems much harder to attack. E.g. -Os has
    recently been improved quite significantly in to-be-gcc-4.2.)

    at least let us allow gcc do it in the CONFIG_CC_OPTIMIZE_FOR_SIZE case,
    -Os means "optimize for space" - no ifs and when, it's a _very_ clear
    and definite goal. I dont think there's much space for gcc to mess up
    there, it's a mostly binary decision: either the inlining of a
    particular function saves space, or not.

    in the other case, when optimizing for speed, the decisions are alot
    less clear, and gcc has arguably alot more leeway to mess up.

    also, there's a fundamental conflict of 'speed vs. performance' here,
    for a certain boundary region. For the extremes, very small and very
    large functions, the decision is clear, but if e.g. a CPU has tons of
    cache, it might prefer more agressive inlining than if it doesnt. So
    it's not like we can do it in a fully static manner.

    > 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?

    this is going to be a never ending battle, and it's not about peanuts
    either: we are talking about 5% of .text space here, on a .config that
    carries most of the important subsystems and drivers. Do we really want
    to take on this battle and fight it for 30,000+ kernel functions - when
    gcc today can arguably do a _better_ job than what we attempted to do
    manually for years? We went to great trouble going to BK just to make
    development easier - shouldnt we let a fully open-source tool like gcc
    make our lives easier and not worry about details like that? Whether to
    inline or not _is_ a mostly thoughtless work with almost zero intellect
    in it. I'd rather trust gcc do it than some script doing the same much
    worse.

    Ingo
    -
    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-29 08:39    [W:0.026 / U:29.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site