Richard Henderson <[EMAIL PROTECTED]> wrote on 19/06/2005 20:33:02:
> On Sun, Jun 19, 2005 at 08:00:22PM +0300, Dorit Naishlos wrote:
> > 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 think this is a bit silly; unless we have a good reason I don't think
> we should define different optabs for constant/non-constant shift counts.
>
The thought was to supply an API that would let the vectorizer ask for the
minimal capability it needs - if all we need is a vector shift of a
constant value in bytes, lets ask exactly for that, so that targets that
don't support non-constant shifts, or that support only byte shifts, could
also enjoy this feature.
A general vector shift that can take both constant and non-constant counts
is indeed more general, and maybe what we prefer to have at the tree level.
In this case, targets that can't tell the vectorizer that they can support
general vector shifts, but could have told the vectorizer that they support
an immediate vector shift, will just have to implement the REDUC_OP
directly (using immediate vector shifts) in their machine description.
dorit
>
> r~
