Richard Biener <richard.guent...@gmail.com> writes: > On Mon, Oct 23, 2017 at 7:41 PM, Richard Sandiford > <richard.sandif...@linaro.org> wrote: >> This patch changes TYPE_VECTOR_SUBPARTS to a poly_uint64. The value is >> encoded in the 10-bit precision field and was previously always stored >> as a simple log2 value. The challenge was to use this 10 bits to >> encode the number of elements in variable-length vectors, so that >> we didn't need to increase the size of the tree. >> >> In practice the number of vector elements should always have the form >> N + N * X (where X is the runtime value), and as for constant-length >> vectors, N must be a power of 2 (even though X itself might not be). >> The patch therefore uses the low bit to select between constant-length >> and variable-length and uses the upper 9 bits to encode log2(N). >> Targets without variable-length vectors continue to use the old scheme. >> >> A new valid_vector_subparts_p function tests whether a given number >> of elements can be encoded. This is false for the vector modes that >> represent an LD3 or ST3 vector triple (which we want to treat as arrays >> of vectors rather than single vectors). >> >> Most of the patch is mechanical; previous patches handled the changes >> that weren't entirely straightforward. > > One comment, w/o actually reviewing may/must stuff (will comment on that > elsewhere). > > You split 10 bits into 9 and 1, wouldn't it be more efficient to use the > lower 8 bits for the log2 value of N and either of the two remaining bits > for the flag? That way the 8 bits for the shift amount can be eventually > accessed in a more efficient way. > > Guess you'd need to compare code-generation of the TYPE_VECTOR_SUBPARTS > accessor on aarch64 / x86_64.
Ah, yeah. I'll give that a go. > Am I correct that NUM_POLY_INT_COEFFS is 1 for targets that do not > have variable length vector modes? Right. 1 is the default and only AArch64 defines it to anything else (2). Thanks, Richard
