From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by sourceware.org (Postfix) with ESMTPS id E6F2C38582A3 for ; Thu, 14 Jul 2022 09:32:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6F2C38582A3 Received: by mail-yb1-xb31.google.com with SMTP id i206so2244351ybc.5 for ; Thu, 14 Jul 2022 02:32:54 -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=uvh+VhqUPNFvBB75dDL3W0ePzobebp/XtuKc6ZZfgf4=; b=wtvho0PJZR1Z5jXuEMh3p8ffuLI+LT8qxojFmfVbhxiTr79b+pkhI0yhegE+iWMI9o Pi4HqE0Z1OyznzrlzPFiYKPiEoyNX8qi5oBgMasv9pLvf2WotzGmxJrBDevY2wqjhNZf xii/+7hnArp+rB+uIVF06ypPC0LAaVhodlEKY3Jy4FVFu+4+hgqON9BH4ksTnCHzOMEP lG+Ptk2KFNDaKnMaOjul1C4/urf4e2eR+qLLK6zzQnVY34MIeGFXQlYSIxLMHYQcMVIe 6KvXEjDbrC8UdU70g8nhhR7+6MpXlHdARgTNojsjkh4YA0qZCiN6I4FNgI4ykI9KO9zA sbhg== X-Gm-Message-State: AJIora9NVCbl94ULpe4jIysbCKsM3+A11Oij0a1vg/vDBW+4GS1Tzozf 6RaUSLKv4Sv8cMingQyE6Jz+3rzCDUsnIJxKDC8= X-Google-Smtp-Source: AGRyM1ttDeAtYeKP3F4cmZG6e7RnomcPxcQQwZ736OFMfOqiyJMhyC8F82rtLEsPLEIhOB+Vd1Rq+Zz6j/4esUfGeDQ= X-Received: by 2002:a05:6902:11c8:b0:664:6d14:4832 with SMTP id n8-20020a05690211c800b006646d144832mr7535860ybu.624.1657791174297; Thu, 14 Jul 2022 02:32:54 -0700 (PDT) MIME-Version: 1.0 References: <20220714053351.7073-1-hongtao.liu@intel.com> In-Reply-To: From: Hongtao Liu Date: Thu, 14 Jul 2022 17:32:43 +0800 Message-ID: Subject: Re: [PATCH] Extend 64-bit vector bit_op patterns with ?r alternative To: Uros Bizjak Cc: liuhongt , "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.5 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:32:56 -0000 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. > > Uros. -- BR, Hongtao