Re: towards reduction part 3/n: what does vec lower pass do to vectorshifts?

[Dorit Naishlos <DORIT at il dot ibm dot com>]

Richard Henderson <rth@redhat.com> wrote on 19/06/2005 19:49:46:
> On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote:
> > ... because at least for the vector-shift case I need to
> > check that the shift operand is constant, and only then return
> > optab_shri/shli.
>
> This isn't true.  Just because the altivec patterns don't accept
> anything other than a constant doesn't mean that the pattern can't
> be valid for other operands.  The operation is completely specified
> by its code.

Altivec does support non immediate shift amount (even if less efficiently -
I have to put the shift amount in a vector register first). But since we
have defined these optabs to represent shift operations that take immediate
shift amount, I shouldn't be returning vec_shli/vec_shri if the shift is
not constant. I could return a "vec_shl_optab"/"vec_shr_optab" that
supported a general shift amount if we wanted to introduce these optabs (in
addition, or instead of "vec_shli_optab/vec_shri_optab"). (For the
vectorizer, immediate shifts would suffice).

>
> Adding the operations to optab_for_tree_code is the right approach.
>
> Ideally we'd also update tree-vect-generic to handle this new operation;
> its behaviour with this code at present is actively wrong.  For the
> moment we should add an assert
>
> ---
>         compute_type = TREE_TYPE (type);
>     }
>
> + gcc_assert (code != VEC_LSHIFT_EXPR && code != VEC_RSHIFT_EXPR);
>   rhs = expand_vector_operation (bsi, type, compute_type, rhs, code);
>   if (lang_hooks.types_compatible_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
> ---
>
> which should verify that we only generate this operation when we have
> the expectation that the backend will handle it.
>

ok,

thanks,

dorit

>
> r~