lkml.org 
[lkml]   [2006]   [Jan]   [2]   [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

    * Adrian Bunk <bunk@stusta.de> wrote:

    > My email was about things like Andi's example of the x86-64 vsyscall
    > code where we really need inlining, and due to your proposed inline
    > semantics change there might be breakages if an __always_inline is
    > forgotten at a place where it was required.

    we can have two types of breakages:

    - stuff wont build if not always_inline. Really easy to find and fix.

    - stuff wont work at all (e.g. vsyscalls) because they have some
    unspecified reliance on gcc's code output. Such code Is Bad anyway,
    and the breakage is still clear: the vsyscalls wont work at all, it's
    quickly found, the appropriate always_inline is inserted, and the
    incident is forgotten.

    talking about 'safer' or 'risky' in this context is misleading, these
    are very clear symptoms which are easy to fix.

    [ If you didnt talk about this uninline patch in the "we have to wait
    one year" comment then please clarify that - all that came through to
    me was some vague "lets wait with this" message, and it wasnt clear
    (to me) which patch it applied to and why. ]

    > Your uninline patch might be simple, but the safe way would be Arjan's
    > approach to start removing all the buggy inline's from .c files.

    sure, that's another thing to do, but it's also clear that there's no
    reason to force inlines in the -Os case.

    There are 22,000+ inline functions in the kernel right now (inlined
    about a 100,000 times), and we'd have to change _thousands_ of them.
    They are causing an unjustified code bloat of somewhere around 20-30%.
    (some of them are very much justified, especially in core kernel code)

    to say it loud and clear again: our current way of handling inlines is
    _FUNDAMENTALLY BROKEN_. To me this means that fundamental changes are
    needed for the _mechanics_ and meaning of inlines. We default to 'always
    inline' which has a current information to noise ratio of 1:10 perhaps.
    My patch changes the mechanics and meaning of inlines, and pretty much
    anything else but a change to the meaning of inlines will still result
    in the same scenario occuring over and over again.

    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: 2006-01-02 11:40    [W:4.731 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site