Messages in this thread | | | From | Nadav Amit <> | Subject | Re: [RFC PATCH 0/5] make use of gcc 9's "asm inline()" | Date | Thu, 29 Aug 2019 18:26:07 +0000 |
| |
> On Aug 29, 2019, at 11:15 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Thu, Aug 29, 2019 at 10:36 AM Nick Desaulniers > <ndesaulniers@google.com> wrote: >> I'm curious what "the size of the asm" means, and how it differs >> precisely from "how many instructions GCC thinks it is." I would >> think those are one and the same? Or maybe "the size of the asm" >> means the size in bytes when assembled to machine code, as opposed to >> the count of assembly instructions? > > The problem is that we do different sections in the inline asm, and > the instruction counts are completely bogus as a result. > > The actual instruction in the code stream may be just a single > instruction. But the out-of-line sections can be multiple instructions > and/or a data section that contains exception information. > > So we want the asm inlined, because the _inline_ part (and the hot > instruction) is small, even though the asm technically maybe generates > many more bytes of additional data. > > The worst offenders for this tend to be > > - various exception tables for user accesses etc > > - "alternatives" where we list two or more different asm alternatives > and then pick the right one at boot time depending on CPU ID flags > > - "BUG_ON()" instructions where there's a "ud2" instruction and > various data annotations going with it > > so gcc may be "technically correct" that the inline asm statement > contains ten instructions or more, but the actual instruction _code_ > footprint in the asm is likely just a single instruction or two. > > The statement counting is also completely off by the fact that some of > the "statements" are assembler directives (ie the > ".pushsection"/".popsection" lines etc). So some of it is that the > instruction counting is off, but the largest part is that it's just > not relevant to the code footprint in that function. > > Un-inlining a function because it contains a single inline asm > instruction is not productive. Yes, it might result in a smaller > binary over-all (because all those other non-code sections do take up > some space), but it actually results in a bigger code footprint.
For the record, here is my failing attempt to address the issue without GCC support:
https://lore.kernel.org/lkml/20181003213100.189959-9-namit@vmware.com/T/
| |