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: Mon, 20 Jun 2005 17:46:51 +0300
- Subject: Re: towards reduction part 3/n: what does vec lower pass do to vectorshifts?
- Reply-to:
- Sensitivity:
Richard Henderson <rth@redhat.com> wrote on 20/06/2005 01:13:11:
> On Sun, Jun 19, 2005 at 11:46:52PM +0300, Dorit Naishlos wrote:
> > 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.
>
> Hmm. In theory we could get this information out of the predicates
> on the expander, but it wouldn't be very clean.
>
> > 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.
>
> At present I believe that most targets implement general shifts.
I once worked on a DSP chip that didn't, but...
> Lets
> just go with that for now. As you say -- there's always a fallback
> option available.
>
...sure, I switched to general vec_shr/shl optabs
thanks,
dorit
>
> r~