From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 15BCF385EC54 for ; Tue, 7 Sep 2021 12:05:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 15BCF385EC54 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.1.2/8.16.0.43) with SMTP id 1879QsS0030623; Tue, 7 Sep 2021 14:05:41 +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 3awyp0tu0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Sep 2021 14:05:41 +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 4EE9F10002A; Tue, 7 Sep 2021 14:05:40 +0200 (CEST) Received: from Webmail-eu.st.com (sfhdag1node3.st.com [10.75.127.3]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 40E7C21C7CD; Tue, 7 Sep 2021 14:05:40 +0200 (CEST) Received: from [10.131.138.188] (10.75.127.45) by SFHDAG1NODE3.st.com (10.75.127.3) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 7 Sep 2021 14:05:39 +0200 Message-ID: Date: Tue, 7 Sep 2021 14:05:39 +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> From: Christophe LYON In-Reply-To: <1f7a948f-dd64-0428-27e3-0f9604c6500c@foss.arm.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.75.127.45] X-ClientProxiedBy: SFHDAG1NODE3.st.com (10.75.127.3) To SFHDAG1NODE3.st.com (10.75.127.3) 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-07_04,2021-09-07_01,2020-04-07_01 X-Spam-Status: No, score=-8.3 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: Tue, 07 Sep 2021 12:05:45 -0000 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? > > R. > > >>     #define FP_SYSREGS \ >>