lkml.org 
[lkml]   [2018]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v9 04/10] x86: refcount: prevent gcc distortions

    * 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

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