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 1B0703858426 for ; Mon, 6 Feb 2023 12:22:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B0703858426 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com 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 101EDFEC; Mon, 6 Feb 2023 04:23:05 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 275083F8C6; Mon, 6 Feb 2023 04:22:22 -0800 (PST) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Roger Sayle , GCC Patches , richard.sandiford@arm.com Cc: Roger Sayle , GCC Patches Subject: Re: [DOC PATCH] Document the VEC_PERM_EXPR tree code (and minor clean-ups). References: <000f01d938d8$00cdf7d0$0269e770$@nextmovesoftware.com> Date: Mon, 06 Feb 2023 12:22:20 +0000 In-Reply-To: (Richard Biener's message of "Mon, 6 Feb 2023 08:10:37 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-29.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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