From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id DEEAD3858CDA for ; Wed, 11 Oct 2023 10:56:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DEEAD3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2A0D6C15; Wed, 11 Oct 2023 03:57:37 -0700 (PDT) Received: from [10.2.78.54] (e120077-lin.cambridge.arm.com [10.2.78.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D40123F5A1; Wed, 11 Oct 2023 03:56:55 -0700 (PDT) Message-ID: Date: Wed, 11 Oct 2023 11:56:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Register allocation cost question To: Andrew Stubbs , Chung-Lin Tang , gcc mailing list References: <9c350ebd-fd67-4975-abee-68787f97c383@codesourcery.com> <8cc599b6-1037-4946-b88a-12a8ebc7cc00@siemens.com> <87f19e88-fad7-4de2-8de7-efab4eff0203@codesourcery.com> Content-Language: en-GB From: "Richard Earnshaw (lists)" In-Reply-To: <87f19e88-fad7-4de2-8de7-efab4eff0203@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3493.9 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/10/2023 09:58, Andrew Stubbs wrote: > On 11/10/2023 07:54, Chung-Lin Tang wrote: >> >> >> On 2023/10/10 11:11 PM, Andrew Stubbs wrote: >>> Hi all, >>> >>> I'm trying to add a new register set to the GCN port, but I've hit a >>> problem I don't understand. >>> >>> There are 256 new registers (each 2048 bit vector register) but the >>> register file has to be divided between all the running hardware >>> threads; if you can use fewer registers you can get more parallelism, >>> which means that it's important that they're allocated in order. >>> >>> The problem is that they're not allocated in order. Somehow the IRA pass >>> is calculating different costs for the registers within the class. It >>> seems to prefer registers a32, a96, a160, and a224. >>> >>> The internal regno are 448, 512, 576, 640. These are not random numbers! >>> They all have zero for the 6 LSB. >>> >>> What could cause this? Did I overrun some magic limit? What target hook >>> might I have miscoded? >>> >>> I'm also seeing wrong-code bugs when I allow more than 32 new registers, >>> but that might be an unrelated problem. Or the allocation is broken? I'm >>> still analyzing this. >>> >>> If it matters, ... the new registers can't be used for general purposes, >>> so I'm trying to set them up as a temporary spill destination. This >>> means they're typically not busy. It feels like it shouldn't be this >>> hard... :( >> >> Have you tried experimenting with REG_ALLOC_ORDER? I see that the GCN port currently isn't using this target macro. > > The default definition is 0,1,2,3,4.... and is already the desired behaviour. > > Andrew You may need to define HONOR_REG_ALLOC_ORDER though.