lkml.org 
[lkml]   [2018]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v9 04/10] x86: refcount: prevent gcc distortions
    From
    On October 4, 2018 2:12:22 AM PDT, Ingo Molnar <mingo@kernel.org> wrote:
    >
    >* Nadav Amit <namit@vmware.com> wrote:
    >
    >> I can run some tests. (@hpa: I thought you asked about the -pipe
    >overhead;
    >> perhaps I misunderstood).
    >
    >Well, tests are unlikely to show the overhead of extra lines of this
    >magnitude, unless done very carefully, yet the added bloat exists and
    >is not even
    >mentioned by the changelog, it just says:
    >
    >Subject: [PATCH v9 02/10] Makefile: Prepare for using macros for inline
    >asm
    >
    > Using macros for inline assembly improves both readability and
    >compilation decisions that are distorted by big assembly blocks that
    >use
    > alternative sections. Compile macros.S and use it to assemble all C
    > files. Currently, only x86 will use it.
    >
    >> I guess you regard to the preprocessing of the assembler. Note that
    >the C
    >> preprocessing of macros.S obviously happens only once. That’s the
    >reason
    >> I assumed it’s not that expensive.
    >
    >True - so first we build macros.s, and that gets included in every C
    >file build, right?
    >
    >macros.s is smaller: 275 lines only in the distro test build I tried,
    >which looks
    >a lot better than my first 4,200 lines guesstimate.
    >
    >> Anyhow, I remember that we discussed at some point doing something
    >like
    >> ‘asm(“.include XXX.s”)’ and somebody said it is not good, but I don’t
    >> remember why and don’t see any reason it is so. Unless I am missing
    >> something, I think it is possible to take each individual header and
    >> preprocess the assembly part of into a separate .s file. Then we can
    >put in
    >> the C part of the header ‘asm(".include XXX.s”)’.
    >>
    >> What do you think?
    >
    >Hm, this looks quite complex - macros.s is better I think. Also, 275
    >straight assembly lines is
    >a lot better than 4,200.
    >
    >Another, separate question I wanted to ask: how do we ensure that the
    >kernel stays fixed?
    >I.e. is there some tooling we can use to actually measure whether
    >there's bad inlining decisions
    >done, to detect all these bad patterns that cause bad GCC code
    >generation?
    >
    >Thanks,
    >
    > Ingo

    The assembly output from GCC is quite volumious; I doubt tacking a few hundred lines on will matter one iota.
    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.

    \
     
     \ /
      Last update: 2018-10-04 11:18    [W:4.087 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site