This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: towards reduction part 3/n: what does vec lower pass do to vectorshifts?
- From: Dorit Naishlos <DORIT at il dot ibm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- Date: Sun, 19 Jun 2005 20:00:22 +0300
- Subject: Re: towards reduction part 3/n: what does vec lower pass do to vectorshifts?
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~