From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id 8214E3858D1E for ; Mon, 6 Feb 2023 14:44:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8214E3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DUlHK7kBvuwVD5sT8aEz5jCg+qG/G8/8a8/cOo/bKmw=; b=CbQeNhHRL1eR0YX5gFr83OD+/3 bAzeX13hbBxUEL7wxZQEMQmdJIsBvHEjDyAzoJYIvkDoA+bgJuTgc3PdWOfXbcVtELYCqEGff0sGS ubC0hlNsaOU3xrunvOxUl1HQTOwKAZbGXUPb9canyclXCLslZmpoAtLt3V76vjmxPbrO+fp+gJsk7 4LBlA//znk2XPhLEt2zt8Z73OMbi51iCiOB/IlDAaGLf7W/0rAc0hnTEkiKSxpF4RnmDVi4X6wWOi 8GAcGYZQT6JFiBZnWcTySn4J4JPSgjRgMT1A1NUCSHtQL+VsMw2chJnfuODixPn+wB3wRH5OtEGHa NRTY5Fcg==; Received: from [185.62.158.67] (port=61721 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pP2jZ-0001vd-8i; Mon, 06 Feb 2023 09:44:41 -0500 From: "Roger Sayle" To: "'Richard Sandiford'" , "'Richard Biener'" Cc: "'GCC Patches'" References: <000f01d938d8$00cdf7d0$0269e770$@nextmovesoftware.com> In-Reply-To: Subject: RE: [DOC PATCH] Document the VEC_PERM_EXPR tree code (and minor clean-ups). Date: Mon, 6 Feb 2023 14:44:39 -0000 Message-ID: <05dc01d93a39$8b8c12a0$a2a437e0$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKfUlZIigG+62QB6fxSLcZxCgaOuQKOrgYcAONH4GqtGj5lYA== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Perhaps I'm missing something (I'm not too familiar with SVE semantics), but is there a reason that the solution for PR96473 uses a VEC_PERM_EXPR and not just a VEC_DUPLICATE_EXPR? The folding of sv1d1rq (svptrue_..., ...) doesn't seem to require either the blending or the permutation functionality of a VEC_PERM_EXPR. Instead, it seems to be misusing (the modified) VEC_PERM_EXPR as a form of VIEW_CONVERT_EXPR that allows us to convert/mismatch the type of the operands to the type of the result. Conceptually, (as in Richard's original motivation for the PR), svint32_t foo (int32x4_t x) { return svld1rq (svptrue_b8 (), &x[0]); } can be optimized to (something like) svint32_t foo (int32x4_t x) { return svdup_32 (x[0]); } // or dup z0.q, z0.q[0] equivalent hence it makes sense for fold to transform the gimple form of the first, into the gimple form of the second(?) Just curious. Roger -- > -----Original Message----- > From: Richard Sandiford > Sent: 06 February 2023 12:22 > To: Richard Biener > Cc: Roger Sayle ; GCC Patches patches@gcc.gnu.org> > Subject: Re: [DOC PATCH] Document the VEC_PERM_EXPR tree code (and minor > clean-ups). > > Richard Biener writes: > > On Sat, Feb 4, 2023 at 9:35 PM Roger Sayle > wrote: > >> > >> > >> This patch (primarily) documents the VEC_PERM_EXPR tree code in > >> generic.texi. For ease of review, it is provided below as a pair of > >> diffs. The first contains just the new text added to describe > >> VEC_PERM_EXPR, the second tidies up this part of the documentation by > >> sorting the tree codes into alphabetical order, and providing > >> consistent section naming/capitalization, so changing this section > >> from "Vectors" to "Vector Expressions" (matching the nearby "Unary > >> and Binary Expressions"). > >> > >> Tested with make pdf and make html on x86_64-pc-linux-gnu. > >> The reviewer(s) can decide whether to approve just the new content, > >> or the content+clean-up. Ok for mainline? > > > > +@item VEC_PERM_EXPR > > +This node represents a vector permute/blend operation. The three > > +operands must be vectors of the same number of elements. The first > > +and second operands must be vectors of the same type as the entire > > +expression, > > > > this was recently relaxed for the case of constant permutes in which > > case the first and second operands only have to have the same element > > type as the result. See tree-cfg.cc:verify_gimple_assign_ternary. > > > > The following description will become a bit more awkward here and for > > rhs1/rhs2 with different number of elements the modulo interpretation > > doesn't hold - I believe we require in-bounds elements for constant > > permutes. Richard can probably clarify things here. > > I thought that the modulo behaviour still applies when the node has a constant > selector, it's just that the in-range form is the canonical one. > > With variable-length vectors, I think it's in principle possible to have a stepped > constant selector whose start elements are in-range but whose final elements > aren't (and instead wrap around when applied). > E.g. the selector could zip the last quarter of the inputs followed by the first > quarter. > > Thanks, > Richard