From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id 57FA73858407 for ; Wed, 8 Sep 2021 07:49:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57FA73858407 Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.1.2/8.16.0.43) with SMTP id 1886q8Wu005700; Wed, 8 Sep 2021 09:49:01 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 3axcmqavmk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Sep 2021 09:49:01 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1285C10002A; Wed, 8 Sep 2021 09:49:00 +0200 (CEST) Received: from Webmail-eu.st.com (gpxdag1node6.st.com [10.75.127.67]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id D8B7E215127; Wed, 8 Sep 2021 09:49:00 +0200 (CEST) Received: from [10.211.9.215] (10.75.127.44) by GPXDAG1NODE6.st.com (10.75.127.67) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 8 Sep 2021 09:49:00 +0200 Message-ID: <92a7e9e4-f561-7fa1-fa16-84c6e6bc1507@foss.st.com> Date: Wed, 8 Sep 2021 09:48:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.0.3 Subject: Re: [PATCH 04/13] arm: Add GENERAL_AND_VPR_REGS regclass Content-Language: en-US To: Richard Earnshaw , References: <20210907091531.1034282-1-christophe.lyon@foss.st.com> <20210907091531.1034282-5-christophe.lyon@foss.st.com> <1f7a948f-dd64-0428-27e3-0f9604c6500c@foss.arm.com> <51e7e252-8f92-95ef-243a-6a211f90ba2f@foss.arm.com> From: Christophe LYON In-Reply-To: <51e7e252-8f92-95ef-243a-6a211f90ba2f@foss.arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.44] X-ClientProxiedBy: SFHDAG2NODE2.st.com (10.75.127.5) To GPXDAG1NODE6.st.com (10.75.127.67) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-09-08_02,2021-09-07_02,2020-04-07_01 X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 07:49:05 -0000 On 07/09/2021 15:35, Richard Earnshaw wrote: > > > On 07/09/2021 13:05, Christophe LYON wrote: >> >> On 07/09/2021 11:42, Richard Earnshaw wrote: >>> >>> >>> On 07/09/2021 10:15, Christophe Lyon via Gcc-patches wrote: >>>> At some point during the development of this patch series, it appeared >>>> that in some cases the register allocator wants “VPR or general” >>>> rather than “VPR or general or FP” (which is the same thing as >>>> ALL_REGS).  The series does not seem to require this anymore, but it >>>> seems to be a good thing to do anyway, to give the register allocator >>>> more freedom. >>>> >>>> 2021-09-01  Christophe Lyon >>>> >>>>     gcc/ >>>>     * config/arm/arm.h (reg_class): Add GENERAL_AND_VPR_REGS. >>>>     (REG_CLASS_NAMES): Likewise. >>>>     (REG_CLASS_CONTENTS): Likewise. Add VPR_REG to ALL_REGS. >>>> >>>> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h >>>> index 015299c1534..fab39d05916 100644 >>>> --- a/gcc/config/arm/arm.h >>>> +++ b/gcc/config/arm/arm.h >>>> @@ -1286,6 +1286,7 @@ enum reg_class >>>>     SFP_REG, >>>>     AFP_REG, >>>>     VPR_REG, >>>> +  GENERAL_AND_VPR_REGS, >>>>     ALL_REGS, >>>>     LIM_REG_CLASSES >>>>   }; >>>> @@ -1315,6 +1316,7 @@ enum reg_class >>>>     "SFP_REG",        \ >>>>     "AFP_REG",        \ >>>>     "VPR_REG",        \ >>>> +  "GENERAL_AND_VPR_REGS", \ >>>>     "ALL_REGS"        \ >>>>   } >>>>   @@ -1343,7 +1345,8 @@ enum reg_class >>>>     { 0x00000000, 0x00000000, 0x00000000, 0x00000040 }, /* SFP_REG >>>> */    \ >>>>     { 0x00000000, 0x00000000, 0x00000000, 0x00000080 }, /* AFP_REG >>>> */    \ >>>>     { 0x00000000, 0x00000000, 0x00000000, 0x00000400 }, /* VPR_REG. >>>> */    \ >>>> -  { 0xFFFF7FFF, 0xFFFFFFFF, 0xFFFFFFFF, 0x0000000F }  /* ALL_REGS. >>>> */    \ >>>> +  { 0x00005FFF, 0x00000000, 0x00000000, 0x00000400 }, /* >>>> GENERAL_AND_VPR_REGS.  */ \ >>>> +  { 0xFFFF7FFF, 0xFFFFFFFF, 0xFFFFFFFF, 0x0000040F }  /* ALL_REGS. >>>> */    \ >>>>   } >>> >>> You've changed the definition of ALL_REGS here (to include VPR_REG), >>> but not really explained why.  Is that the source of the underlying >>> issue with the 'appeared' you mention? >> >> >> I first added VPR_REG to ALL_REGS, but Richard Sandiford suggested I >> create a new GENERAL_AND_VPR_REGS that would be more restrictive. I >> did not remove VPR_REG from ALL_REGS because I thought it was an >> omission: shouldn't ALL_REGS contain all registers? > > Surely that should be a separate patch then. OK, I can remove that line from this patch and make a separate one-liner for ALL_REGS. Thanks, Christophe > > R. > >> >> >>> >>> R. >>> >>> >>>>     #define FP_SYSREGS \ >>>>