From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by sourceware.org (Postfix) with ESMTPS id D9A233858C39 for ; Tue, 12 Jul 2022 07:15:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D9A233858C39 Received: by mail-qv1-xf35.google.com with SMTP id r12so1997354qvm.3 for ; Tue, 12 Jul 2022 00:15:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qtX8ym5mu4mJm5iesS3NHpXUUnQsCzvievMhOSifPzU=; b=4c6M4zi9MXb3t5fPylgL0zUnryuxYeIkVwMItGcCSqpGl84wXd5zDR/0fseWxc76No swClp1Yzg/pW53Os7dyAAObOE7ITFkFOSfe60L84DT54px/zQNo1ADitzaiOc7XjL/zz /PtONBAf+73MjLV6v+48kFDAd0HA+4dFXNCuxRsehbx5sKLRqdMXoGZ8NciA0DrgcS+X WsPNVsZbsGAp2bYaUsss9TdgtKmvMIQIYQslzgfDZ7bEXS9CpjKmenEpmPmXIpVRhvuY pmhzzHCqlcNEfpPbLCiA6wKWnl9DPj0mCLDz9d24MWOfwZuUsax2CmoAkXKtLm6QGZW2 DojQ== X-Gm-Message-State: AJIora9uUH3wXdSjRmtA8IgcV/LYA2VHmOEhXJpAARxn1eqh8aP8T4Pc IN9rB64N5brAHZVyKGoe66JtfTb7/aTJuDF/BLk3b6T6gCA= X-Google-Smtp-Source: AGRyM1tNzmBtcEYnj5UC5w7UxJpjhgIaSK9AFM9w6bLQw/DBNbmMYjLFEd6tk537HF+OpZeGT1grvj+IyCOBBF5qPOY= X-Received: by 2002:ad4:5765:0:b0:473:20f:fc09 with SMTP id r5-20020ad45765000000b00473020ffc09mr16893243qvx.2.1657610117161; Tue, 12 Jul 2022 00:15:17 -0700 (PDT) MIME-Version: 1.0 References: <20220711011506.103835-1-hongtao.liu@intel.com> In-Reply-To: From: Uros Bizjak Date: Tue, 12 Jul 2022 09:15:06 +0200 Message-ID: Subject: Re: [PATCH] Allocate general register(memory/immediate) for 16/32/64-bit vector bit_op patterns. To: Hongtao Liu Cc: liuhongt , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 12 Jul 2022 07:15:19 -0000 On Tue, Jul 12, 2022 at 8:37 AM Hongtao Liu wrote: > > On Mon, Jul 11, 2022 at 4:03 PM Uros Bizjak via Gcc-patches > wrote: > > > > On Mon, Jul 11, 2022 at 3:15 AM liuhongt wrote: > > > > > > And split it to GPR-version instruction after reload. > > > > > > This will enable below optimization for 16/32/64-bit vector bit_op > > > > > > - movd (%rdi), %xmm0 > > > - movd (%rsi), %xmm1 > > > - pand %xmm1, %xmm0 > > > - movd %xmm0, (%rdi) > > > + movl (%rsi), %eax > > > + andl %eax, (%rdi) > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > > > Ok for trunk? > > > > The patch will create many interunit moves (xmm <-> gpr) for anything > > but the most simple logic sequences, because operations with > > memory/immediate will be forced into GPR registers, while reg/reg > > operations will remain in XMM registers. > Agree not to deal with mem/immediate at first. > > > > I tried to introduce GPR registers to MMX logic insns in the past and > > observed the above behavior, but perhaps RA evolved in the mean time > > to handle different register sets better (especially under register > > pressure). However, I would advise to be careful with this > > functionality. > > > > Perhaps this problem should be attacked in stages. First, please > > introduce GPR registers to MMX logic instructions (similar to how > > VI_16_32 mode instructions are handled). After RA effects will be > There's "?r" in VI_16_32 logic instructions which prevent RA allocate > gpr for testcase in the patch. > Is it ok to remove "?" for them(Also add alternative "r" instead of > "?r" in mmx logic insns)? > If there's other instructions that prefer "v to "r", then RA will > allocate "v", but for logic instructions, "r" and =E2=80=9Cv" should be > treated equally, just as in the 16/32/64-bit vector > mov_internal. ?r was introduced under the assumption that we want vector values mostly in vector registers. Currently there are no instructions with memory or immediate operand, so that made sense at the time. Let's keep ?r until logic instructions with mem/imm operands are introduced. So, for the patch that adds 64-bit vector logic in GPR, I would advise to first introduce only register operands. mem/imm operands should be added in a follow-up patch when the "?r" constraint will also be relaxed. Uros.