Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Nadav Amit <namit@vmware.com>
To:     Nick Desaulniers <ndesaulniers@google.com>
CC:     Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Joe Perches <joe@perches.com>
Subject: Re: [RFC PATCH 0/5] make use of gcc 9's "asm inline()"
Thread-Topic: [RFC PATCH 0/5] make use of gcc 9's "asm inline()"
Thread-Index: AQHVXkRaBqsQuToWZEu27cwbsZAFCqcSY/cAgAAK3ACAAAMVAA==
Date:   Thu, 29 Aug 2019 18:26:07 +0000
Message-ID: <6C70DE15-0F83-4CBB-B25B-EFF50BC34DD3@vmware.com>
References: <20190829083233.24162-1-linux@rasmusvillemoes.dk>
 <CAKwvOdnUXiX_cAUTSpqgYJTUERoRF-=3LfaydvwBWC6HtzfEdg@mail.gmail.com>
 <CAHk-=wgZ7Ge8QUkkSZLCfJBsHRsre65DkfTyZ2Kt5VPwa=dkuA@mail.gmail.com>
In-Reply-To: <CAHk-=wgZ7Ge8QUkkSZLCfJBsHRsre65DkfTyZ2Kt5VPwa=dkuA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: vmware.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25C9E7220D8711439952559944FB54E9@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 37749bd7-c923-43b0-d438-08d72cae5bd0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 18:26:07.0549
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GQuRXP3mz4ftQS4b1kfc/0/ou3S4IgqHTgiRZ769+dnJk5bLVig4YM7Xx01BOIMLAmR17iSYjRZ2lZcYv1yC3g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4357
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> On Aug 29, 2019, at 11:15 AM, Linus Torvalds <torvalds@linux-foundation.o=
rg> wrote:
>=20
> 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?
>=20
> The problem is that we do different sections in the inline asm, and
> the instruction counts are completely bogus as a result.
>=20
> 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.
>=20
> 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.
>=20
> The worst offenders for this tend to be
>=20
> - various exception tables for user accesses etc
>=20
> - "alternatives" where we list two or more different asm alternatives
> and then pick the right one at boot time depending on CPU ID flags
>=20
> - "BUG_ON()" instructions where there's a "ud2" instruction and
> various data annotations going with it
>=20
> 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.
>=20
> 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.
>=20
> 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/