Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2686985ybl; Thu, 29 Aug 2019 11:28:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqx2Ctbe0+l72VimRA60CtAscOOqUnDN3lzqV25F0RMg09evURKZ0jIRTmYtmt54bg19Rfv2 X-Received: by 2002:a62:e50f:: with SMTP id n15mr10566215pff.208.1567103322324; Thu, 29 Aug 2019 11:28:42 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1567103322; cv=pass; d=google.com; s=arc-20160816; b=GhpA+9xajbhGexxbOrQNUeBr0kftVSaYk6maUWv+16uiQ6RQgjS8P3w4NbIqlQ4Atf lzX21ttRN/EYWuq+Y6X6Y4Gs8t+DT3IDlu/WKvowZ5Ki9l0ewdV/iGnjPyqjk8N/tcCb rdNSLfzbTJieSLIChdrDgPyV+5lPB5gT599z4pmf/H1fag2mk5jmiSUBkhZcw0AjOEO9 4Q7McRSkIKw/nykU3TpOxjx2FSckc+3gbzjrKWoJZyP2GWeYIkobYmOdX5Hq4CDL3KpX TJEpfqS9WRa/bSyXmVa+HTprgb8QU+cRxnSGXjgRkfNo47AuR5ShgTYIkahs0hWSU1Uo aq/w== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-id:content-language:accept-language:in-reply-to:references :message-id:date:thread-index:thread-topic:subject:cc:to:from :dkim-signature; bh=Elrp7tMe2s1X81AeQz29M0s1ma9HJ+JlK12Fr9GFqkw=; b=C/BqC/q3JMdcbIVeKlsZIg3fw/1ti7ZouGHN+6z/oIfB76e/kqqxD73k65rFGC+t23 nwIUdYIZqLJLlfNNtxE8jqTeCW9nSqmBTq+CUnvQ1VxP3UOEjGTZ8h8gOhAtb+vAEFfu R0UDna5RNWi/70ZipjA6pXJ/vMlxMpYKjCMsIgMkSpvjPr7Lp7kW7PVoN9O1puoUkZal cJ3+4vGS4YaX4rh36+SNBWEMtO8tN3mvyOL/rVdc0cjBmp0zUmfs4gA1DOFcYHNrAUIh 62m3AbL/3Yr9qG7vAso0Smr5ntGjSgMnpbQbh4LKKR/bf16dq5dQETWSXamZ+w0W4BOe /TIg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@vmware.com header.s=selector2 header.b=TweL8QRV; arc=pass (i=1 spf=pass spfdomain=vmware.com dkim=pass dkdomain=vmware.com dmarc=pass fromdomain=vmware.com); spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s61si2584660plb.426.2019.08.29.11.28.26; Thu, 29 Aug 2019 11:28:42 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@vmware.com header.s=selector2 header.b=TweL8QRV; arc=pass (i=1 spf=pass spfdomain=vmware.com dkim=pass dkdomain=vmware.com dmarc=pass fromdomain=vmware.com); spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729890AbfH2S0M (ORCPT + 99 others); Thu, 29 Aug 2019 14:26:12 -0400 Received: from mail-eopbgr750082.outbound.protection.outlook.com ([40.107.75.82]:14597 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729851AbfH2S0J (ORCPT ); Thu, 29 Aug 2019 14:26:09 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hdXWoYD5lIlG8Ck4EXYCt16oLjnEhqVcFOM1GwXaHJiFxg5rRqUGr43gzh4Cs6QCmausyM1/RcDJKOoIvyJx6Z1Jc4wtB43snjEvchfe+cRd8+AUaTfoEP9nIBhjJ+2mu/yGnzPL0NaqrnEmjilU5/ZeNlrNfmbcefwkieFF9zCuMRca64kpIYqMsCUIKuG5V7vLMvgHNAq7+QpQK1jXOo2Ja5VKxsBUG+O/BS1omOObQ59A2P+UmhR9YZr3aMfbqbDY5wITr+hNE6k6rEh/iiD8AQ6ZMheNcuXgCnLGUqXSuXmVmW3OSl5KzIdRlmsFf7T9DIpLo3qk+YaNhoJaSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Elrp7tMe2s1X81AeQz29M0s1ma9HJ+JlK12Fr9GFqkw=; b=SGXJx4SPR8Qa/CNEeC54GCsMhEaMopWoFS6Rs9h7vk19j26m9aKxTMvySvJ59mmChNkVTI8lRbPWAMyOXsw404W8sRqVvN+lnmT8TPtc5ajXNn8wuNMRlUFA2iMh8TVh1IaItLzqXVyUjGMjPLORzItJWtoLI0Jhk9JK4rbjzjzWZ8U8cvyUB4QGcTSI6UlMJWbO1K/+JnsqzY/Aq3ad2YNG6QUKRwpCuoRx+E5dB5ZTu0ddnS9sh/yIKRz4hgIp9fOU1tKTvL9g4DZb1C9q621laIco9c1Jtd6lAV4KW8gZI48ntLM+2mHKnx78PzlrdxUfOH27U1NJJ7DRWld3Ig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Elrp7tMe2s1X81AeQz29M0s1ma9HJ+JlK12Fr9GFqkw=; b=TweL8QRVAwoN7n/ViFo5zmwU1vKWwwT9AuiArbO2Hds4VdwpvLJrDSiE35rJdjdWldn5RimyIz0/klp0lin6rQKo3WLyuil9QAwH0y+HDKINPlSQmV5SD6egIjXc6KKo/N0FQxhS0LXqtJj1ecOyUU0TK0+0EeXbBD8YaAx1htA= Received: from BYAPR05MB4776.namprd05.prod.outlook.com (52.135.233.146) by BYAPR05MB4357.namprd05.prod.outlook.com (20.176.250.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.5; Thu, 29 Aug 2019 18:26:07 +0000 Received: from BYAPR05MB4776.namprd05.prod.outlook.com ([fe80::5163:1b6f:2d03:303d]) by BYAPR05MB4776.namprd05.prod.outlook.com ([fe80::5163:1b6f:2d03:303d%3]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 18:26:07 +0000 From: Nadav Amit To: Nick Desaulniers CC: Rasmus Villemoes , Linus Torvalds , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , LKML , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Miguel Ojeda , Masahiro Yamada , clang-built-linux , Joe Perches 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=namit@vmware.com; x-originating-ip: [66.170.99.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 37749bd7-c923-43b0-d438-08d72cae5bd0 x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020);SRVR:BYAPR05MB4357; x-ms-traffictypediagnostic: BYAPR05MB4357: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(4636009)(39860400002)(366004)(136003)(396003)(346002)(376002)(199004)(189003)(11346002)(486006)(6436002)(476003)(446003)(256004)(36756003)(71190400001)(71200400001)(478600001)(26005)(102836004)(6506007)(53546011)(6916009)(186003)(14454004)(305945005)(3846002)(6116002)(7736002)(8936002)(76176011)(2616005)(7416002)(966005)(99286004)(54906003)(316002)(229853002)(86362001)(6486002)(76116006)(8676002)(81156014)(81166006)(33656002)(66946007)(66446008)(64756008)(66556008)(25786009)(4326008)(53936002)(6246003)(6306002)(6512007)(5660300002)(66066001)(66476007)(2906002);DIR:OUT;SFP:1101;SCL:1;SRVR:BYAPR05MB4357;H:BYAPR05MB4776.namprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uSCqbOGjA/Ud0PS3bnOqm/0o4MB9qDhnybCSr1Ojw6m1fzPGytR4mlo8+lQ9c9bvElsNMfc0nmA0vytwK0FlvSaIvdPwrNqI70izMfpudAQHDvP8CFFfuCKcRwGYHu/OT1eZL0/nTVwQAHZbok22/eBlolKciOf3l1wQxgKOath5AA08HW6c0GtVwKh8Ae9yiii9D9MCoRxOt1iP39kg28z1zHuQuumnb83XGJusMWk7DjDnB/NPw1iKvu69/x4yPjRQVs8A77DaHBtjvdVLEQ5hf6wz30NAsVzJZR9NALODGCCr0b8msUVDW1iMYj1E8wbpFek0ZBcPOoIsr9IGam0t/iPwgl4qmJtBzgPbreegvgjpKwbWOKr0zC7Zn6uI7XoCRrRXM0HNKGhfXewrvA+Kiy+NJCoGYJ9npLpb9Lc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <25C9E7220D8711439952559944FB54E9@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: vmware.com 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: X-Mailing-List: linux-kernel@vger.kernel.org > On Aug 29, 2019, at 11:15 AM, Linus Torvalds wrote: >=20 > On Thu, Aug 29, 2019 at 10:36 AM Nick Desaulniers > 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/