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 081453858C66 for ; Fri, 1 Sep 2023 11:03:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 081453858C66 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 5B022FEC; Fri, 1 Sep 2023 04:04:01 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C87333FBD2; Fri, 1 Sep 2023 04:03:21 -0700 (PDT) From: Richard Sandiford To: Uros Bizjak via Gcc-patches Mail-Followup-To: Uros Bizjak via Gcc-patches ,Jakub Jelinek , Uros Bizjak , Hongyu Wang , hongtao.liu@intel.com, hubicka@ucw.cz, richard.sandiford@arm.com Cc: Jakub Jelinek , Uros Bizjak , Hongyu Wang , hongtao.liu@intel.com, hubicka@ucw.cz Subject: Re: [PATCH 06/13] [APX EGPR] Map reg/mem constraints in inline asm to non-EGPR constraint. References: <20230831082024.314097-1-hongyu.wang@intel.com> <20230831082024.314097-7-hongyu.wang@intel.com> Date: Fri, 01 Sep 2023 12:03:20 +0100 In-Reply-To: (Uros Bizjak via Gcc-patches's message of "Thu, 31 Aug 2023 12:00:40 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-25.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,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: Uros Bizjak via Gcc-patches writes: > On Thu, Aug 31, 2023 at 11:18=E2=80=AFAM Jakub Jelinek via Gcc-patches > wrote: >> >> On Thu, Aug 31, 2023 at 04:20:17PM +0800, Hongyu Wang via Gcc-patches wr= ote: >> > From: Kong Lingling >> > >> > In inline asm, we do not know if the insn can use EGPR, so disable EGPR >> > usage by default from mapping the common reg/mem constraint to non-EGPR >> > constraints. Use a flag mapx-inline-asm-use-gpr32 to enable EGPR usage >> > for inline asm. >> > >> > gcc/ChangeLog: >> > >> > * config/i386/i386.cc (INCLUDE_STRING): Add include for >> > ix86_md_asm_adjust. >> > (ix86_md_asm_adjust): When APX EGPR enabled without specifying t= he >> > target option, map reg/mem constraints to non-EGPR constraints. >> > * config/i386/i386.opt: Add option mapx-inline-asm-use-gpr32. >> > >> > gcc/testsuite/ChangeLog: >> > >> > * gcc.target/i386/apx-inline-gpr-norex2.c: New test. >> > --- >> > gcc/config/i386/i386.cc | 44 +++++++ >> > gcc/config/i386/i386.opt | 5 + >> > .../gcc.target/i386/apx-inline-gpr-norex2.c | 107 ++++++++++++++++++ >> > 3 files changed, 156 insertions(+) >> > create mode 100644 gcc/testsuite/gcc.target/i386/apx-inline-gpr-norex= 2.c >> > >> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc >> > index d26d9ab0d9d..9460ebbfda4 100644 >> > --- a/gcc/config/i386/i386.cc >> > +++ b/gcc/config/i386/i386.cc >> > @@ -17,6 +17,7 @@ You should have received a copy of the GNU General P= ublic License >> > along with GCC; see the file COPYING3. If not see >> > . */ >> > >> > +#define INCLUDE_STRING >> > #define IN_TARGET_CODE 1 >> > >> > #include "config.h" >> > @@ -23077,6 +23078,49 @@ ix86_md_asm_adjust (vec &outputs, vec & /*inputs*/, >> > bool saw_asm_flag =3D false; >> > >> > start_sequence (); >> > + /* TODO: Here we just mapped the general r/m constraints to non-EGPR >> > + constraints, will eventually map all the usable constraints in the= future. */ >> >> I think there should be some constraint which explicitly has all the 32 >> GPRs, like there is one for just all 16 GPRs (h), so that regardless of >> -mapx-inline-asm-use-gpr32 one can be explicit what the inline asm wants. >> >> Also, what about the "g" constraint? Shouldn't there be another for "g" >> without r16..r31? What about the various other memory >> constraints ("<", "o", ...)? > > I think we should leave all existing constraints as they are, so "r" > covers only GPR16, "m" and "o" to only use GPR16. We can then > introduce "h" to instructions that have the ability to handle EGPR. Yeah. I'm jumping in without having read the full thread, sorry, but the current mechanism for handling this is TARGET_MEM_CONSTRAINT (added for s390). That is, TARGET_MEM_CONSTRAINT can be defined to some new constraint that is more general than the traditional "m" constraint. This constraint is then the one that is associated with memory_operand etc. "m" can then be defined explicitly to the old definition, so that existing asms continue to work. So if the port wants generic internal memory addresses to use the EGPR set (sounds reasonable), then TARGET_MEM_CONSTRAINT would be a new constraint that maps to those addresses. Thanks, Richard