From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::70d]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9AF511A1DF5 for ; Thu, 4 Aug 2016 11:08:44 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 4 Aug 2016 18:08:40 +0000 Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) with mapi id 15.01.0549.022; Thu, 4 Aug 2016 18:08:40 +0000 From: "Cohen, Eugene" To: Ard Biesheuvel , Leif Lindholm CC: "edk2-devel@lists.01.org" Thread-Topic: Managing GCC Assembly Code Size (AArch64) Thread-Index: AdHua3mGruyS3HJHS1Sm2wPict8MmA== Date: Thu, 4 Aug 2016 18:08:40 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eugene@hp.com; x-originating-ip: [15.65.254.4] x-ms-office365-filtering-correlation-id: 55e67aa9-94ca-4fc3-8d1e-08d3bc925d7f x-microsoft-exchange-diagnostics: 1; AT5PR84MB0291; 6:SBes8sDXFY2mXQbK7I5u2/Mnhy+HFWTsK374BZhWy6kAZprrEQGl4KYUiQeEoZk4U98QDb8N1zyB1HomYxoGPzn9jfptFRegebmEeAxGxNgxu5wE3rqpRxRm7vkD93caNnXX1Cw8yjDi50ZFLED00fPPymfsn6T1+lRrbXGluhgyF0dqjpaVl3kMv9ynUv/dWiavtq76kc+6gGXW7lcCmk83Z0nVMuaguSUb5Z+J1CJJNAjmD0CwbkI8PKagxcJMRz481CXMYX8NRMlmKstkVspjclaaGIjaYDu/Qq7PoQQ=; 5:HxUS28CHpVr0r2YVZf+jF5F14KMPlHoHjlO4WmXBrFGCmcupGcOPz8cpaMq/Q5JDdebm/PkfIPyUL6eoXQUyEgpkRcjBx3adAJuPZp1AH2asM2TZdRYKq0XKwP2nUbZN9zfAsKwxSrKhp3VgxI0AYg==; 24:6rkixa8h45Ibhme2SYtldDEghdhHr7eUoeZqcXBW/I1vBAsfJOwIfKVv06yMW0QgZ+HHvNAnr/a9nvPA9yLwM/C1ZZ0kXgVPGEwx6eb1u00=; 7:u9Gf0iLH61aII8OWVSEY02SG3Wf72FnXULc7RjmqEo81Y/JTXNNakQD8JU5A3TxfZMkxRSOogvXpY8Kv70nEdljYsHikxiqVV1Z+4XBgyFFBwpXqPktq67hpkBZCVwqVwGyB5dbOG8AxDD0pKEAyE/x7wmnQtM5dNAmQV8Xjt+kQvGMENDjDTl6JZhgVcKjcWM04livAmVTq4xT7m6oCM8s0iOZ/CbXBjGRipBNDz9PUc6x2AxA/P5W4aRk6EaaX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0291; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AT5PR84MB0291; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0291; x-forefront-prvs: 00246AB517 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(6602003)(199003)(8676002)(8936002)(81156014)(77096005)(81166006)(122556002)(106356001)(3660700001)(11100500001)(7736002)(7696003)(7846002)(68736007)(87936001)(99286002)(189998001)(4326007)(101416001)(9686002)(92566002)(586003)(2906002)(66066001)(97736004)(5002640100001)(10400500002)(229853001)(86362001)(3280700002)(33656002)(74316002)(2900100001)(6116002)(3846002)(5001770100001)(102836003)(105586002)(50986999)(54356999)(305945005)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0291; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2016 18:08:40.7577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0291 Subject: Managing GCC Assembly Code Size (AArch64) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 18:08:44 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ard and Leif, I've been too backlogged to provide a real patchset at this point but wante= d to get your approval on this proposal... As you know we have some code size sensitive uncompressed XIP stuff going o= n. For C code we get dead code stripping thanks to the "-ffunction-section= s" switch which places each function in its own section so the linker can s= trip unreferenced sections. For assembly there is not a solution that's as easy. For RVCT we handled t= his with an assembler macro that combined the procedure label definition, e= xport of global symbols and placement of the procedure in its own section. = For GCC I haven't found a way to fully do this because we rely on the C pr= eprocessor for assembly which means you cannot expand to multi-line macros.= (The label and assembler directives require their own lines but the prepr= ocessor collapses stuff onto one line because in the C language newlines do= n't matter.) So the solution I've settled on is to do this: in MdePkg\Include\AArch64\ProcessorBind.h define: /// Macro to place a function in its own section for dead code eliminatio= n /// This must be placed directly before the corresponding code since the /// .section directive applies to the code that follows it. #define GCC_ASM_EXPORT_SECTION(func__) \ .global _CONCATENATE (__USER_LABEL_PREFIX__, func__) ;\ .section .text._CONCATENATE (__USER_LABEL_PREFIX__, func__) ;= \ .type ASM_PFX(func__), %function; \ This has the effect of placing the function in a section called .text. so the linker can do its dead code stripping stuff. It also absorbs th= e making the symbol globally visible so the corresponding GCC_ASM_EXPORT st= atement can be removed. then for every single assembly procedure change from this: [top of file] GCC_ASM_EXPORT (ArmInvalidateDataCacheEntryByMVA) [lower down] ASM_PFX(ArmInvalidateDataCacheEntryByMVA): dc ivac, x0 // Invalidate single data cache line ret to this: GCC_ASM_EXPORT_SECTION(ArmInvalidateDataCacheEntryByMVA) ASM_PFX(ArmInvalidateDataCacheEntryByMVA): dc ivac, x0 // Invalidate single data cache line ret Because the assembly label must appear in column 1 I couldn't find a way to= use the C preprocessor to absorb it so hence the two lines. If you can fi= nd a way to improve on this it would be great. I'm not sure what impacts this might have to other toolchains - can this be= translated to CLANG and ARM Compiler? I'd like to get your OK on this conceptually and then I could upstream some= patches that modify the AArch64 *.S files to use this approach. Unfortuna= tely it won't be complete because I only updated the libraries that we use.= My hope is that long term all assembly (or at least assembly in libraries= ) adopt this approach so we are positioned for maximum dead code stripping. Thanks, Eugene