Messages in this thread | | | From | Nadav Amit <> | Subject | Re: [PATCH v9 04/10] x86: refcount: prevent gcc distortions | Date | Thu, 4 Oct 2018 08:56:37 +0000 |
| |
at 1:40 AM, hpa@zytor.com wrote:
> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar <mingo@kernel.org> wrote: >> * Ingo Molnar <mingo@kernel.org> wrote: >> >>> I'm also somewhat annoyed at the fact that this series carries a >> boatload >>> of reviewed-by's and acked-by's, yet none of those reviewers found it >>> important to point out the large chasm that is gaping between >> description >>> and reality. >> >> Another problem I just realized is that we now include >> arch/x86/kernel/macros.S in every >> translation pass when building the kernel, right? >> >> But arch/x86/kernel/macros.S expands to a pretty large hiearchy of >> header files: >> >> $ make arch/x86/kernel/macros.s >> >> $ cat $(grep include arch/x86/kernel/macros.s | cut -d\" -f2 | sort | >> uniq) | wc -l >> 4128 >> >> That's 4,100 extra lines of code to be preprocessed for every >> translation unit, of >> which there are tens of thousands. More if other pieces of code get >> macrofied in >> this fasion in the future. >> >> If we assume that a typical distribution kernel build has ~20,000 >> translation units >> then this change adds 82,560,000 more lines to be preprocessed, just to >> work around >> a stupid GCC bug? >> >> I'm totally unhappy about that. Can we do this without adding macros.S? >> >> It's also a pretty stupidly central file anyway that moves source code >> away >> from where it's used. >> >> Thanks, >> >> Ingo > > It's not just for working around a stupid GCC bug, but it also has a huge > potential for cleaning up the inline asm in general. > > I would like to know if there is an actual number for the build overhead > (an actual benchmark); I have asked for that once already.
I can run some tests. (@hpa: I thought you asked about the -pipe overhead; perhaps I misunderstood).
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.
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?
| |