Re: [DOC PATCH] Document the VEC_PERM_EXPR tree code (and minor clean-ups).

[Richard Sandiford <richard.sandiford@arm.com>]

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