Richard Biener <richard.guent...@gmail.com> writes: > On Sat, Feb 4, 2023 at 9:35 PM Roger Sayle <ro...@nextmovesoftware.com> 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
