From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id E84F63857408 for ; Thu, 14 Jul 2022 07:22:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E84F63857408 Received: by mail-qk1-x733.google.com with SMTP id c17so649900qkl.4 for ; Thu, 14 Jul 2022 00:22:15 -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=DGtN2kM2o95oPkkDNRteFT2OPzrYogqAjewAXb/aF38=; b=8AcC9Z51GrQLVkxdY0JhRlqUOFUOMTm1PYowMteTU22W8s/9/9fBg/bE4sV/Wbvtga Z2UWvW6APEUr/q+LkHEtJ6dOLHzuspoaT2jYcw0FNdCg2CBsmGoWN+wIxs340Naqy/67 e+XZ/RVBXpZgEWFJXnotgg21Q3qui2ivXK8//j6gbWG0NI1BXebeIIXvgT87mIlOyD+d a6bgwuidafVqXRR2YH4eGCW6hTF2KeclO0hKad1NLJhH/cuOJMP9AQ5Gdg0lx99kh7HB IzU5CSPWAzLJO49OUqZI6maN69gUGldMuQ+pLJSDsczpcOuxBSjOCT366Rhw1deakjwj Xaeg== X-Gm-Message-State: AJIora/tk1EnglW6y8+KA2UQZNkLvzP6mrsou0sMFYgZii+Xzo2LQGEg 31UzynwSqLKXoCPoxvrCipxiGcgaqwrs6q3yv8w= X-Google-Smtp-Source: AGRyM1sz4fPDqhj/+V9MH2RG3U2gwEHAviQlL40S1dfqyvFfPCB5zZBVCc+9o+AKH+VrRMNQx0AqNXz6g0sWFM4w7cs= X-Received: by 2002:a05:620a:450c:b0:6b2:59b8:985 with SMTP id t12-20020a05620a450c00b006b259b80985mr5022380qkp.328.1657783335194; Thu, 14 Jul 2022 00:22:15 -0700 (PDT) MIME-Version: 1.0 References: <20220714053351.7073-1-hongtao.liu@intel.com> In-Reply-To: <20220714053351.7073-1-hongtao.liu@intel.com> From: Uros Bizjak Date: Thu, 14 Jul 2022 09:22:04 +0200 Message-ID: Subject: Re: [PATCH] Extend 64-bit vector bit_op patterns with ?r alternative To: liuhongt Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 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 07:22:19 -0000 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. 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... Uros.