From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by sourceware.org (Postfix) with ESMTPS id 4BB8F3858D33 for ; Mon, 4 Sep 2023 00:28:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4BB8F3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-d7e9d849bdfso669268276.3 for ; Sun, 03 Sep 2023 17:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693787299; x=1694392099; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LEQxCHSxguaHYcbO73Xp6EWZdRWlacZlxS8hr7EGWRk=; b=AzVV2aEmPkGcpazHi5jLwx/Wg3c/UnVi0XEdV2GZdnKS43jrbriPaz7EHWDDBG3X07 FdzuFGWRFveBTIBIeixkLWz6IWOH+tAjAP7VJp4qlLaZNIIq1zLIQHN48JTWIOP+RDAZ yUqg+qUXDCr+qe6FBQsZ4nWtu8GoEL9aNPzDJc9t37xWeCR6NfGT6fyPAlPDI9QWcYOL 6yxRDRglSPf18moiZJAZEyxzQ1vKpUqkaav8kft4yZQFW3QRLQCtJIEQgsaJMCM20GfV rcXDAG7yRyZlfZjK9MuQ10RZgdTDicVumiXr+YCI0e1U7q6TZSelXhDlkyLI3P4NNyoQ M1NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693787299; x=1694392099; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LEQxCHSxguaHYcbO73Xp6EWZdRWlacZlxS8hr7EGWRk=; b=DEYZGiIhlij1bXMbzQAIg4S59B/QcDo0VpYGEHTEYrpdbwbYrc3ZXr604/AkdL64aF vCktYH4AqtWj0YGu9bC/6pmgYyISfqZcea6ITnFBjFYLPtFOZUrJ7n6FrMNGbkEce2Do rbYIOHmhzMSD/2Iyi53fDdL/K4IwVX+zhj2j4Ai25/CgSwXDmDEnoMLhCV6vap2Ejlcg y1PlmoY1rfcsGYRmxHtwd1xNOTVNKUwOf8WWGCSwR1L+O01GiNQATjuPGXFhjS08kFr7 BBXWKjk3QEXidKaqF6WQczuKrnUWBDxLzloOB34dTD+9K0QishOmOqZwl+ITZhtLPgWa C3LQ== X-Gm-Message-State: AOJu0YyNvmL5ooqUjV9nPxsfCgWWyqvno15KJwOr3fK/jzrZcVwFSbBZ 0l6FED6yAiyhjEVfsFsoCq0Iq/YJJfJsjXQr4oQ= X-Google-Smtp-Source: AGHT+IEuPbGHkICrh4NldfHoNNbdHZN5DUCAuyuhnG/lmN2DtNNCwJBwk2NmguFrPZFOZydkkfe9vke/ie0anFb/qAo= X-Received: by 2002:a25:a564:0:b0:d7a:c6f6:69b with SMTP id h91-20020a25a564000000b00d7ac6f6069bmr9074644ybi.5.1693787299580; Sun, 03 Sep 2023 17:28:19 -0700 (PDT) MIME-Version: 1.0 References: <20230831082024.314097-1-hongyu.wang@intel.com> <20230831082024.314097-7-hongyu.wang@intel.com> In-Reply-To: From: Hongtao Liu Date: Mon, 4 Sep 2023 08:28:07 +0800 Message-ID: Subject: Re: [PATCH 06/13] [APX EGPR] Map reg/mem constraints in inline asm to non-EGPR constraint. To: Uros Bizjak Cc: Hongyu Wang , Jakub Jelinek , Hongyu Wang , gcc-patches@gcc.gnu.org, hongtao.liu@intel.com, hubicka@ucw.cz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 Fri, Sep 1, 2023 at 7:27=E2=80=AFPM Uros Bizjak wrot= e: > > On Fri, Sep 1, 2023 at 12:36=E2=80=AFPM Hongtao Liu = wrote: > > > > On Fri, Sep 1, 2023 at 5:38=E2=80=AFPM Uros Bizjak via Gcc-patches > > wrote: > > > > > > On Fri, Sep 1, 2023 at 11:10=E2=80=AFAM Hongyu Wang wrote: > > > > > > > > Uros Bizjak via Gcc-patches =E4=BA=8E2023= =E5=B9=B48=E6=9C=8831=E6=97=A5=E5=91=A8=E5=9B=9B 18:01=E5=86=99=E9=81=93=EF= =BC=9A > > > > > > > > > > On Thu, Aug 31, 2023 at 11:18=E2=80=AFAM Jakub Jelinek via Gcc-pa= tches > > > > > wrote: > > > > > > > > > > > > On Thu, Aug 31, 2023 at 04:20:17PM +0800, Hongyu Wang via Gcc-p= atches wrote: > > > > > > > From: Kong Lingling > > > > > > > > > > > > > > In inline asm, we do not know if the insn can use EGPR, so di= sable EGPR > > > > > > > usage by default from mapping the common reg/mem constraint t= o non-EGPR > > > > > > > constraints. Use a flag mapx-inline-asm-use-gpr32 to enable E= GPR 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 spe= cifying the > > > > > > > target option, map reg/mem constraints to non-EGPR cons= traints. > > > > > > > * 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-norex2.c > > > > > > > > > > > > > > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.c= c > > > > > > > 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 Public 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 &output= s, vec & /*inputs*/, > > > > > > > bool saw_asm_flag =3D false; > > > > > > > > > > > > > > start_sequence (); > > > > > > > + /* TODO: Here we just mapped the general r/m constraints t= o non-EGPR > > > > > > > + constraints, will eventually map all the usable constrain= ts in the future. */ > > > > > > > > > > > > I think there should be some constraint which explicitly has al= l the 32 > > > > > > GPRs, like there is one for just all 16 GPRs (h), so that regar= dless 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 anothe= r 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 EGP= R. > > > > > This would be somehow similar to the SSE -> AVX512F transition, w= here > > > > > we still have "x" for SSE16 and "v" was introduced as a separate > > > > > register class for EVEX SSE registers. This way, asm will be > > > > > compatible, when "r", "m", "o" and "g" are used. The new memory > > > > > constraint "Bt", should allow new registers, and should be added = to > > > > > the constraint string as a separate constraint, and conditionally > > > > > enabled by relevant "isa" (AKA "enabled") attribute. > > > > > > > > The extended constraint can work for registers, but for memory it i= s more > > > > complicated. > > > > > > Yes, unfortunately. The compiler assumes that an unchangeable registe= r > > > class is used for BASE/INDEX registers. I have hit this limitation > > > when trying to implement memory support for instructions involving > > > 8-bit high registers (%ah, %bh, %ch, %dh), which do not support REX > > > registers, also inside memory operand. (You can see the "hack" in e.g= . > > > *extzvqi_mem_rex64" and corresponding peephole2 with the original > > > *extzvqi pattern). I am aware that dynamic insn-dependent BASE/INDEX > > > register class is the major limitation in the compiler, so perhaps th= e > > > strategy on how to override this limitation should be discussed with > > > the register allocator author first. Perhaps adding an insn attribute > > > to insn RTX pattern to specify different BASE/INDEX register sets can > > > be a better solution than passing insn RTX to the register allocator. > > > > > > The above idea still does not solve the asm problem on how to select > > > correct BASE/INDEX register set for memory operands. > > The current approach disables gpr32 for memory operand in asm_operand > > by default. but can be turned on by options > > ix86_apx_inline_asm_use_gpr32(users need to guarantee the instruction > > supports gpr32). > > Only ~ 5% of total instructions don't support gpr32, reversed approach > > only gonna get more complicated. > > I'm not referring to the reversed approach, just want to point out > that the same approach as you proposed w.r.t. to memory operand can be > achieved using some named insn attribute that would affect BASE/INDEX > register class selection. The attribute could default to gpr32 with > APX, unless the insn specific attribute has e.g. nogpr32 value. See > for example how "enabled" and "preferred_for_*" attributes are used. > Perhaps this new attribute can also be applied to separate > alternatives. Yes, for xop/fma4/3dnow instructions, I think we can use isa attr like (define_attr "gpr32" "0, 1" (cond [(eq_attr "isa" "fma4") (const_string "0")] (const_string "1"))) But still, we need to adjust memory constraints in the pattern. Ideally, gcc includes encoding information for every instruction, (.i.e. map0/map1), so that we can determine the attribute value of gpr32 directly from this information. > > Uros. --=20 BR, Hongtao