From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 2B4A93857C60 for ; Fri, 13 Aug 2021 09:03:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B4A93857C60 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BDBF81042; Fri, 13 Aug 2021 02:03:43 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E97263F70D; Fri, 13 Aug 2021 02:03:42 -0700 (PDT) From: Richard Sandiford To: Jakub Jelinek via Gcc-patches Mail-Followup-To: Jakub Jelinek via Gcc-patches , Hongtao Liu , Richard Biener , Jakub Jelinek , liuhongt , richard.sandiford@arm.com Cc: Hongtao Liu , Richard Biener , Jakub Jelinek , liuhongt Subject: Re: [PATCH] [i386] Optimize vec_perm_expr to match vpmov{dw,qd,wb}. References: <20210812054323.897480-1-hongtao.liu@intel.com> <20210812092248.GY2380545@tucnak> <20210813084753.GG2380545@tucnak> Date: Fri, 13 Aug 2021 10:03:41 +0100 In-Reply-To: <20210813084753.GG2380545@tucnak> (Jakub Jelinek via Gcc-patches's message of "Fri, 13 Aug 2021 10:47:53 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 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, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 13 Aug 2021 09:03:45 -0000 Jakub Jelinek via Gcc-patches writes: > On Fri, Aug 13, 2021 at 09:42:00AM +0800, Hongtao Liu wrote: >> > So, I wonder if your new routine shouldn't be instead done after >> > in ix86_expand_vec_perm_const_1 after vec_perm_1 among other 2 insn ca= ses >> > and handle the other vpmovdw etc. cases in combine splitters (see that= we >> > only use low half or quarter of the result and transform whatever >> > permutation we've used into what we want). >> > >> Got it, i'll try that way. > > Note, IMHO the ultimate fix would be to add real support for the > __builtin_shufflevector -1 indices (meaning I don't care what will be in > that element, perhaps narrowed down to an implementation choice of > any element of the input vector(s) or 0). > As VEC_PERM_EXPR is currently used for both perms by variable permutation > vector and constant, I think we'd need to introduce VEC_PERM_CONST_EXPR, > which would be exactly like VEC_PERM_EXPR, except that the last operand > would be required to be a VECTOR_CST and that all ones element would mean > something different, the I don't care behavior. > The GIMPLE side would be fairly easy, except that there should be some > optimizations eventually, like when only certain subset of elements of > a vector are used later, we can mark the other elements as don't care. Another alternative I'd wondered about was keeping a single tree code, but adding an extra operand with a =E2=80=9Ccare/don't care=E2=80=9D mask. = I think that would fit with variable-length vectors better. Thanks, Richard