From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by sourceware.org (Postfix) with ESMTPS id B429D3853821 for ; Thu, 14 Jul 2022 09:46:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B429D3853821 Received: by mail-qt1-x834.google.com with SMTP id cf13so958298qtb.13 for ; Thu, 14 Jul 2022 02:46:45 -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; bh=zQxh2zCpnxsg/EgNP8faV7Gv9K5JKgsiTwnAeN2V8zQ=; b=nX/0/mKcnWf4WnSJUj48uPfBMs4kVbbF5CXqLsHRlq61EDKCmirMSW9QNDryTv3seH rOFr1Lgse/rvixe8sYvtbq+m08hUy567Ajp2PiajPNhHAF0kdDEtJ1K4RmH5QRPLu9bR QfFUhEFXHiGHewHmMT0qcxNjtWdeOxBJWaIj3K6ZC01ufahi4AuVgsI4gVhTBKLEI6Dw Fp/sUzw+13siRQSslP40A5TOzr75gYoVavfw82bm+jRyvm1wRfOEu/AZ/lemTrU9cDLu A+u7NKn/pKEnKSwuuEDi0H7lvMBKszbPbOArd3U7C/l5eRBqQyzfEhh3dgqj4BxMT4YQ VOxA== X-Gm-Message-State: AJIora87Vqhn27oeHkt6eBedEhuXUEfoEtlQH5GlXGAPfjrdRi7bqXS5 gn2sakg11G98/m/vGyv0Cf+xLaWfIDRJTvRlX3w= X-Google-Smtp-Source: AGRyM1vFAWejJKDLxjPwDa3b1uog1p1knAcMXeh9z6V8BLtJC5W6UAxOM1NHePgql+CPDn54nRfKESeEv8O1v+9xvJw= X-Received: by 2002:a05:622a:213:b0:31e:c569:220e with SMTP id b19-20020a05622a021300b0031ec569220emr7111360qtx.436.1657792005036; Thu, 14 Jul 2022 02:46:45 -0700 (PDT) MIME-Version: 1.0 References: <20220714053351.7073-1-hongtao.liu@intel.com> In-Reply-To: From: Uros Bizjak Date: Thu, 14 Jul 2022 11:46:34 +0200 Message-ID: Subject: Re: [PATCH] Extend 64-bit vector bit_op patterns with ?r alternative To: Hongtao Liu Cc: liuhongt , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 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: Thu, 14 Jul 2022 09:46:47 -0000 On Thu, Jul 14, 2022 at 11:32 AM Hongtao Liu wrote: > > On Thu, Jul 14, 2022 at 3:22 PM Uros Bizjak via Gcc-patches > wrote: > > > > On Thu, Jul 14, 2022 at 7:33 AM liuhongt wrote: > > > > > > And split it to GPR-version instruction after reload. > > > > > > > ?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 > > > Update patch to add ?r to 64-bit bit_op patterns. > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}. > > > No big imact on SPEC2017(Most same binary). > > > > The problem with your approach is with the combine pass, where combine > > first tries to recognize the combined instruction without clobber, > > before re-recognizing instruction with added clobber. So, if a forward > > propagation happens, the combine will *always* choose the insn variant > > without GPR. > Thank you for the explanation, I really did not know this point. > > > > So, the solution with VI_16_32 is to always expand with a clobbered > > version that is split to either SImode or V16QImode. With 64-bit > > instructions, we have two additional complications. First, we have a > > native MMX instruction, and we have to split to it after reload, and > > second, we have a builtin that expects vector insn. > > > > To solve the first issue, we should change the mode of > > "*mmx" to V1DImode and split your new _gpr version with > > clobber to it for !GENERAL_REG_P operands. > > > > The second issue could be solved by emitting V1DImode instructions > > directly from the expander. Please note there are several expanders > > that expect non-clobbered logic insn in certain mode to be available, > > so the situation can become quite annoying... > Yes. It looks like it would add a lot of code complexity, I'll hold > the patch for now. I did some experimenting in the past with the idea of adding GPR instructions to 64-bit vectors. While there were some opportunities with 32- and 16-bit operations, mostly due to the fact that these arguments are passed via integer registers, 64-bit cases never triggered, because 64-bit vectors are passed via XMM registers. Also, when mem/imm alternatives were added, many inter-regunit moves were generated for everything but the most simple testcases involving logic operations, also considering the limited range of 64-bit immediates. IMO, the only case it is worth adding is a direct immediate store to memory, which HJ recently added. Uros. Uros.