Jakub Jelinek <ja...@redhat.com> writes: > On Thu, Nov 23, 2017 at 02:43:32PM +0100, Michael Matz wrote: >> > If it's a VEC_PERM_EXPR then it'll be a new form of VEC_PERM_EXPR. >> >> No, it'd be a VEC_PERM_EXPR where the magic mask is generated by a new >> EXPR type, instead of being a mere constant. > > Or an internal function that would produce the permutation mask vector > given kind and number of vector elements and element type for the mask.
I think this comes back to what to the return type of the functions should be. A vector of QImodes wouldn't be wide enough when vectors are 256 elements or wider, so we'd need a vctor of HImodes with the same number of elements as a native vector of QImodes. This means that the function will need to return a non-native vector type. That doesn't matter if the function remains glued to the VEC_PERM_EXPR, but once we expose it as a separate operation, it can get optimised separately from the VEC_PERM_EXPR. Also, even with this representation, the operation isn't truly variable-length. It just increases the maximum number of elements from 256 to 65536. That ought to be enough realistically (in the same way that 640k ought to be enough realistically), but the patches as posted have avoided needing to encode a maximum like that. Having the internal function do the permute rather than produce the mask means that the operation really is variable-length: we don't require a vector index to fit within a specific integer type. Thanks, Richard
