From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53234 invoked by alias); 5 Sep 2017 21:28:05 -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 52050 invoked by uid 89); 5 Sep 2017 21:28: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= X-HELO: EUR01-DB5-obe.outbound.protection.outlook.com Received: from mail-db5eur01on0042.outbound.protection.outlook.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (104.47.2.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Sep 2017 21:27:57 +0000 Received: from DB6PR0801MB2053.eurprd08.prod.outlook.com (10.168.86.22) by DB6PR0801MB1877.eurprd08.prod.outlook.com (10.168.85.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Tue, 5 Sep 2017 21:27:54 +0000 Received: from DB6PR0801MB2053.eurprd08.prod.outlook.com ([fe80::2d78:6ac0:142:cc9a]) by DB6PR0801MB2053.eurprd08.prod.outlook.com ([fe80::2d78:6ac0:142:cc9a%18]) with mapi id 15.20.0013.018; Tue, 5 Sep 2017 21:27:54 +0000 From: Wilco Dijkstra To: Bernd Edlinger , Christophe Lyon , Kyrill Tkachov CC: Ramana Radhakrishnan , GCC Patches , Richard Earnshaw , nd Subject: Re: [PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308) Date: Tue, 05 Sep 2017 21:28:00 -0000 Message-ID: References: <59AD6894.7010605@foss.arm.com> , In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DB6PR0801MB1877;6:Gz8+ibBOd/bgUvxkndtene//LH2hseLmst68owOTTTW1/a2Gw//nRwmHtCFz/ewc9aO9VSpRFny+WgI5LfElAXHDB8AKCwBCAeoLSqU5+NwCqys5d4dLv94F+Bk1g1wT9fDtYSJLSx+GcLGSgNliMryV/oTPbl2RIEsr1rbjy1vqL9+SdeUaMSZyV7j3qkcdQNaLGKl4GmV1oKZNk9CtavXcSmVo5cHptGLve0ArgIlxhBvOde5QRvsCMFkoXOvwpfYx3H3N9fgZn9y3CdPJkP5/lKBqhDzofIvTr2j+Ik+i2d7Iv9LzdMnfVgGeuVbUoqklZLAuEWS/deM3W24xPg==;5:Zk7oHYsC/4C6/iqOZJpiYhe6lWGyY+dmQYMNoK5znUxt+Td1IDamu+XJvzB07gwo48bcdkTLRXUtSkqc89wZzu7g1cnvysx2GEemvSjaBUjcu5sHuptaPOphIC1pVnHV1175n1IiTljbqLu4qWjOtg==;24:2Y+xoPNYYtcHjYsiig/qSECoN+eprlqIfEDWPNw7Sy71zYUYtos2M1Z0WJqKLR3bAruOo12mZOV3SWrWvYZeRULKAAEbghPizIPsGpPmhaE=;7:Lo9Jn2Mcljx1lw/bV+1B/YtsJ4rp+ac1Bn5n/hPV1no94ZLALLX0CQSrxncH9kHkV0nu6WnQJAzE0o3Ft9fp0epEUa7uHt4SZz9STKT5M9MyF7z0x+zXPoD5sezc5OpwsXcGJjaJOAGJbH3a35R3AXFxzhFa3nHFxOHmBKuY44hnc7dcMQpWwEXe4aJ7Tp8etMLzjuegMRh/7Ed77mR6BChi3Hrkg3XrRz9YqwDIDus= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 626af671-1a91-408e-225b-08d4f4a4f838 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DB6PR0801MB1877; x-ms-traffictypediagnostic: DB6PR0801MB1877: nodisclaimer: True x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DB6PR0801MB1877;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DB6PR0801MB1877; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(199003)(189002)(24454002)(2900100001)(74316002)(102836003)(6116002)(33656002)(68736007)(189998001)(4326008)(478600001)(6246003)(25786009)(5660300001)(7696004)(72206003)(93886005)(3846002)(86362001)(97736004)(2950100002)(9686003)(3660700001)(106356001)(3280700002)(2906002)(105586002)(66066001)(81156014)(54906002)(81166006)(53936002)(8676002)(229853002)(99286003)(7736002)(6436002)(101416001)(305945005)(8936002)(6506006)(76176999)(50986999)(54356999)(55016002)(5250100002)(14454004);DIR:OUT;SFP:1101;SCL:1;SRVR:DB6PR0801MB1877;H:DB6PR0801MB2053.eurprd08.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX: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: 05 Sep 2017 21:27:54.1856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1877 X-SW-Source: 2017-09/txt/msg00304.txt.bz2 Bernd Edlinger wrote: > No, the split condition does not begin with "&& TARGET_32BIT...". > Therefore the split is enabled in TARGET_NEON after reload_completed. > And it is invoked from adddi3_neon for all alternatives without vfp > registers: Hmm that's a huge mess. I'd argue that any inst_and_split should only split it's own instruction, never other instructions (especially if they are from different md files, which is extremely confusing). Otherwise we should use a separate split and explicitly list which instructions it splits. So then the next question is whether the neon_adddi3 still needs the arm_adddi3 splitter in some odd corner cases? > > Also there are more cases, a quick grep suggests *anddi_notdi_di has th= e same issue.=20 > Yes, that pattern can be cleaned up in a follow-up patch. And there are a lot more instructions that need the same treatment and split early (probably best at expand time). I noticed none of the zero/sign exten= ds split before regalloc for example. > Note this splitter is invoked from bicdi3_neon as well. > However I think anddi_notdi_di should be safe as long as it is enabled > after reload_completed (which is probably a bug). Since we should be splitting and/bic early now I don't think you can get an= ddi_notdi anymore. So it could be removed completely assuming Neon already does the r= ight thing. It looks like we need to do a full pass over all DI mode instructions and c= lean up all the mess. Wilco