From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21779 invoked by alias); 7 Dec 2018 19:01:32 -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 21765 invoked by uid 89); 7 Dec 2018 19:01:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=banks, modeling, bank X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Dec 2018 19:01:30 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F236C3002A3C; Fri, 7 Dec 2018 19:01:28 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-17.rdu2.redhat.com [10.10.112.17]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8A3A85D9C6; Fri, 7 Dec 2018 19:01:27 +0000 (UTC) Subject: Re: [RFA] [target/87369] Prefer "bit" over "bfxil" To: Wilco Dijkstra , Richard Earnshaw , James Greenhalgh Cc: GCC Patches , nd References: From: Jeff Law Openpgp: preference=signencrypt Message-ID: <5db0709f-f1db-5d5b-09d3-f153e8eea317@redhat.com> Date: Fri, 07 Dec 2018 19:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00498.txt.bz2 On 12/7/18 11:48 AM, Wilco Dijkstra wrote: > 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. As I've noted, adding those unspecs is likely to get in the way of things like CSE, combine, etc. > >> 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. I'm not sure what you mean by it can't cost them. Costs certainly factor into the algorithms used by IRA/LRA. But I would agree that it's not particularly good at costing across register banks and modeling the cost of reloads it'll have to generate if it needs to move a value from one bank to another. > > We simply need to make an early choice which register file to use. GCC fundamentally isn't designed to do that. > >> 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. Well, the bfxil pattern is general enough to handle both, the problem is it only works on one register file. > >> 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. I'm going to step away from this problem. It looked like it might be trackable, but there's clearly a lot more to it and someone with more experience on aarch64 will have to run with it. Patch withdrawn. jeff