From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41573 invoked by alias); 7 Dec 2018 18:48:43 -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 41194 invoked by uid 89); 7 Dec 2018 18:48:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hmm X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr30083.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.107.3.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Dec 2018 18:48:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L1bZXi74tLzgNWK1uEdWAYUWtA0NCXasEstT2YyXt+E=; b=Rs7J7b5NC0hEAyKqBtXvhG4WhSYSoMahGvfymwwAVVoRFonSXD3yNqPAg9MUGPPpV8IMm8Sz6bpiWI/vXryuFlCDiSt+KlL+K2TzcswEQxwTH/yEIxIvh7n2MbvnCjmiRiIvpkpQQJYbWStCrTHlZ5/o2jXkRnazpiAPIO+fWhM= Received: from HE1PR08MB1035.eurprd08.prod.outlook.com (10.166.125.145) by HE1PR08MB2828.eurprd08.prod.outlook.com (10.170.246.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Fri, 7 Dec 2018 18:48:08 +0000 Received: from HE1PR08MB1035.eurprd08.prod.outlook.com ([fe80::7c4d:5426:7ce7:5a17]) by HE1PR08MB1035.eurprd08.prod.outlook.com ([fe80::7c4d:5426:7ce7:5a17%4]) with mapi id 15.20.1404.021; Fri, 7 Dec 2018 18:48:07 +0000 From: Wilco Dijkstra To: Jeff Law , Richard Earnshaw , James Greenhalgh CC: GCC Patches , nd Subject: Re: [RFA] [target/87369] Prefer "bit" over "bfxil" Date: Fri, 07 Dec 2018 18:48:00 -0000 Message-ID: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2018-12/txt/msg00497.txt.bz2 Hi, >> Ultimately, the best solution here will probably depend on which we >> think is more likely, copysign or the example I give above. > I'd tend to suspect we'd see more pure integer bit twiddling than the > copysign stuff. All we need to do is to clearly separate the integer and FP/SIMD cases. Copysign should always expand into a pattern that cannot generate integer instructions. This could be done by adding a bit/bif pattern with UNSPEC for the DI/SImode case or use V2DI/V2SI in the copysign expansion. =20 > Could we have the bfxil pattern have an alternative that accepts vector > regs and generates bit in appropriate circumstances? We already do that in too many cases, and it only makes the problem worse since the register allocator cannot cost these patterns at all (let alone accurately). This is particularly bad when the expansions are wildly different and emit extra instructions which cannot be optimized after register allocation. We simply need to make an early choice which register file to use. > Hmm, maybe the other way around would be better. Have the "bit" > pattern with a general register alternative that generates bfxil when > presented with general registers. We already have that, and that's a very complex pattern which already results in inefficient integer code. For the overlapping cases between bfi and bfxil the mid-end should really simplify one into the other to avoid having to have multiple MD patterns for equivalent expressions. This may solve the problem. > I would generally warn against hiding things in unspecs like you've > suggested above. We're seeing cases where that's been on in the x86 > backend and it's inhibiting optimizations in various places. In the general case we can't describe a clear preference for a specific register file without support for scalar vector types (eg. V1DI, V1SI) or having a way to set virtual register preferences at expand time. Wilco