On Wed, Oct 5, 2011 at 8:57 PM, Richard Henderson <r...@redhat.com> wrote:
> These patterns:
>
>> (define_insn "avx2_lshlqv4di3"
>> [(set (match_operand:V4DI 0 "register_operand" "=x")
>> (ashift:V4DI (match_operand:V4DI 1 "register_operand" "x")
>> (match_operand:SI 2 "const_0_to_255_mul_8_operand"
>> "n")))]
>> "TARGET_AVX2"
>> {
>> operands[2] = GEN_INT (INTVAL (operands[2]) / 8);
>> return "vpslldq\t{%2, %1, %0|%0, %1, %2}";
>> }
> ...
>> (define_insn "avx2_lshrqv4di3"
>> [(set (match_operand:V4DI 0 "register_operand" "=x")
>> (lshiftrt:V4DI
>> (match_operand:V4DI 1 "register_operand" "x")
>> (match_operand:SI 2 "const_0_to_255_mul_8_operand" "n")))]
>> "TARGET_AVX2"
>> {
>> operands[2] = GEN_INT (INTVAL (operands[2]) / 8);
>> return "vpsrldq\t{%2, %1, %0|%0, %1, %2}";
>
> are incorrect. This is a 128-bit lane shift, i.e. V2TImode.
>
> Uros, do you have an opinion on whether we should add V2TImode to
> the set of modes, which means adding that to the move patterns.
> Although given the scarse number of operations that we'd be able
> to perform on V2TImode, perhaps it is better to simply use an unspec.
We already have V2TImode, but hidden in VIMAX_AVX2 mode iterator.
Based on that, I would suggest that we model correct insn
functionality and try to avoid unspec. On the related note, there is
no move insn for V2TImode, so V2TI should be added to V16 mode
iterator and a couple of other places (please grep for V1TImode, used
for SSE full-register shift insns only).
Uros.
