From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79098 invoked by alias); 13 Jan 2017 19:51:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 79088 invoked by uid 89); 13 Jan 2017 19:51:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=HContent-Language:en-GB, late X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-he1eur01on0079.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (104.47.0.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Jan 2017 19:50:52 +0000 Received: from AM5PR0802MB2610.eurprd08.prod.outlook.com (10.175.46.18) by AM5PR0801MB2081.eurprd08.prod.outlook.com (10.168.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Fri, 13 Jan 2017 19:50:48 +0000 Received: from AM5PR0802MB2610.eurprd08.prod.outlook.com ([10.175.46.18]) by AM5PR0802MB2610.eurprd08.prod.outlook.com ([10.175.46.18]) with mapi id 15.01.0845.014; Fri, 13 Jan 2017 19:50:48 +0000 From: Wilco Dijkstra To: James Greenhalgh CC: Ramana Radhakrishnan , GCC Patches , nd Subject: Re: [PATCH][AArch64 - v3] Simplify eh_return implementation Date: Fri, 13 Jan 2017 19:51:00 -0000 Message-ID: References: ,<20170113175441.GA38433@arm.com> In-Reply-To: <20170113175441.GA38433@arm.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; x-ms-office365-filtering-correlation-id: 30bcf9d5-0d31-4a76-c1bc-08d43bed78e3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM5PR0801MB2081; x-microsoft-exchange-diagnostics: 1;AM5PR0801MB2081;7:9PbP5Qxc6tgbu7T6DmI5x5gmkJxgzG94n8ztaFbRUYZgTkhWk2rUi00+b+wGyZi1Wof0ntR6LxD25E7RZM4RZcnbTQ1yehiIFr863sEVv4eQ9al2nunL3qhdgmB7LWaHMX+msh4PYb/xfRHdkegIqqxtqBx4O2WlxPllQJyUYvBBtsn8SYyfe/hK9oJE4qvHWOka3kBjzjYrI1c8ZDNsfZKFoLQmIw/5gzKDKWFWlshcnKeF6hV9qkCl8/F6nk8HCdIVE3/nHn/uPbAqvpEjXH7s+Vwp6zd3Dn+AC9fp5EJem87QW3g3lQSav10sDkbAwP/CgldA4Y8k6rMRBqYIBf9KZ36upuWI3gBV+zAH5hX113seK9yZxSWsaPzU4hA3B/beayraJsZhA+S5HEPZ+wiep9UdjfTVzvk7Qcf6TWhcdSqUiZ0sTKctU/Kf/eE/lPm/qCYpBxS/O2pDzdASLQ== nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6072148);SRVR:AM5PR0801MB2081;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB2081; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(39840400002)(39860400002)(39410400002)(39450400003)(39850400002)(189002)(24454002)(199003)(81156014)(81166006)(77096006)(8676002)(33656002)(25786008)(5660300001)(92566002)(93886004)(66066001)(2900100001)(68736007)(4326007)(7736002)(97736004)(27001)(189998001)(6506006)(122556002)(55016002)(101416001)(54906002)(305945005)(99286003)(76176999)(450100001)(54356999)(50986999)(3280700002)(9686003)(3660700001)(8936002)(106356001)(102836003)(3846002)(6636002)(2950100002)(105586002)(74316002)(7696004)(6436002)(2906002)(86362001)(6116002)(38730400001)(110136003)(229853002)(106116001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR0801MB2081;H:AM5PR0802MB2610.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 19:50:48.6061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB2081 X-SW-Source: 2017-01/txt/msg00995.txt.bz2 James Greenhalgh wrote: > I've been putting off reviewing this patch for a while now, because I don= 't > understand enough about the current eh_return code to understand why what > you're proposing is correct. > > The best way to progress this patch would be to go in to more detail as to > what the current code does, why we don't need it, and why your new > implementation is sufficient. The current code looks like it covers speci= al > cases, and calls out DSE and CSELIB as needing special handling - your > new code doesn't. >=20 > Could you explain your patch to me assuming I know very little about the > implementation, with particular focus on why we no longer need the special > cases? Well eh_return is far more complex than the few lines of assembly code it w= as intending to avoid... Basically the EH return feature wants the capability to either return norma= lly or return to a previous frame after unwinding. Oddly enough the design is to use a si= ngle shared return sequence. The epilog is exactly like a normal epilog except that it = has an extra input register which contains the stack adjustment which must be applied af= ter the frame has been destroyed. An extra label is inserted before the eplilog whi= ch sets this stack adjustment to zero, and this is the entry point for a normal return.= =20 An EH return updates the return address, initializes the stack adjustment a= nd jumps directly into the epilog (bypassing the zeroing of the adjustment). Sounds = insane already? Well it gets worse... Given the return address is typically saved on the stack when a function ma= kes a=20 call, we now need to overwrite the saved LR outside the epilog. This poses = a problem=20 as we need to emit this store before the epilog is emitted, ie. before the = offset of LR is=20 even known. We also need to ensure the store is not removed.=20 The existing implementation tries to do this by using a special eh_return p= attern which emits the store as late as possible (at least after the frame layout has be= en finalized). However it doesn't do this late enough so DSE is still run after it... To try to avoid DSE removing the store, the existing implementation tries t= o make the=20 store alias with the load by using the same base register and offset. Given= the epilog=20 always reads LR from SP, it follows that whenever FP is used for the store,= it will be optimized away. Even when it uses SP as the base for the store, SP may be updated in the ep= ilog before LR is read (for example alloca functions or frames with large locals or out= going arguments will update SP before reading LR). Worse, the offset it uses for the store = is incorrect, so if the store is not optimized, it just corrupts a random callee-save rather th= an overwriting LR. So basically to conclude the existing implementation only works for one spe= cific case where there are a specific number of callee-saves, no floating point regist= ers, no outgoing arguments, no alloca used, a small number of locals, and frame pointer is e= nabled. The new implementation is trivially correct by forcing the use of a frame p= ointer so that the location of LR is fixed, known early, and using a volatile means no opt= imization could remove the store. It's also much simpler by avoiding all the workarounds us= ing patterns, splitters and trying to ensure the store appears not dead. Wilco