From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 755AE385840C for ; Wed, 11 Oct 2023 08:57:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 755AE385840C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-CSE-ConnectionGUID: gg5KEkQcSiucXZP1AP9C8w== X-CSE-MsgGUID: 0OvAxxJUQQ+yrTidOdFbiw== X-IronPort-AV: E=Sophos;i="6.03,214,1694764800"; d="scan'208";a="21626873" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 11 Oct 2023 00:57:51 -0800 IronPort-SDR: 6Qjcz0BtOGUMriOmbP5titZetvcssAQiHJFK5gCooMteKB8KZY0R/gXD6ymtgh9CNQpMobMlNb xB9m+W0LogNVMm5EaoWyVSKje8/TXYwUojH/sKCVn5UvCpREcliH65yXd6AQUy1BLzhSRkEcJ5 uyGId5PgFKYn+vJNonyfY81kdvSwh/vJpB87TYTVEk4YvvPDE4KWBXYmid7lmt2x2tXg6cgrg2 TqyusimjY9xy8jUspLPc62tvJZnxHIlf0fSF4Eef0NGpdBZmbInhWTQU+4yjZT1vHytvEu5yPv c+8= Message-ID: <8df01cc8-7662-450b-b183-b9be96df26fb@codesourcery.com> Date: Wed, 11 Oct 2023 09:57:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Register allocation cost question Content-Language: en-GB To: Segher Boessenkool CC: gcc mailing list References: <9c350ebd-fd67-4975-abee-68787f97c383@codesourcery.com> <20231010190930.GV19790@gate.crashing.org> From: Andrew Stubbs In-Reply-To: <20231010190930.GV19790@gate.crashing.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no 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 10/10/2023 20:09, Segher Boessenkool wrote: > Hi Andrew, > > On Tue, Oct 10, 2023 at 04:11:18PM +0100, Andrew Stubbs wrote: >> 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. > > It could be connected. both things should not happen. > >> If it matters, ... the new registers can't be used for general purposes, > > What does this mean? I think you mean they *can* be used for anything, > you just don't want to (maybe it is slow)? If you make it allocatable > registers, they *will* be allocated for anythin the compilers deems a > good idea. Nope, the "Accelerator VGPR" registers are exclusively for the use of the new matrix multiply instructions that we don't support (yet). The compiler is free to use them for storing data, but there are no real instructions to do there. >> 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... :( > > So what did you do, put them later in the allocation order? Make their > register_move_cost higher than for normal registers (but still below > memory_move_cost)? Or what? TARGEt_SPILL_CLASS maybe? We put them in a new register class, with a new constraint, and implemented the move instructions (only) with new alternatives for the new class. Then implemented TARGET_SPILL_CLASS in the obvious way. All this is working just fine as long as there are only 32 new registers unfixed (a0-a31); the code even runs correctly and I can see the spilling happening correctly. If I enable register a32 then it prefers that, and I get wrong code. Using that register ought to be logically correct, albeit suboptimal, so I don't understand that either. Andrew