Re: [PATCH] Auto vectorize cond expr (remaining patches)

[Devang Patel <dpatel at apple dot com>]

On Apr 9, 2005, at 12:02 AM, Richard Henderson wrote:

> On Thu, Mar 31, 2005 at 04:29:41PM -0800, Devang Patel wrote:
> > This is remaining bits of vectorizing cond expr bits I posted in
> > last sept.
>
> Please recall that apple's mailer is broken and mangles patches.

Usually I attach my patches, but this time I did cut-n-paste.

> > This patch adds support to 1) vectorize conditional
> > expressions (using vec_cond_optab). 2) It also adds support to check
> > dependence distance wrt vectorization factor. This work was
> > presented in two different patches in sept. (along with 4 other
> > patches but these two missed GCC 4.0 train.). This patches are
> > used in autovect-branch and apple-ppc-branch since last 6 months.
>
> I found one of these, I think,
>
>   http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02889.html
>
> but not the other, and even the one basically has no commentary
> on what you're trying to do.

Yes, this message is the last in this thread. The basic idea is simple.
If dependence distance is more than vectorization factor then it
does not prevent vectorization. If dependence distance is zero then
also it does not hurt vectorization.

Another is at

    http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01768.html

and it has some info and pointers to other messages. I included
dependence vector patch together because now it is very small
thanks to other changes in vectorizer.

> I definitely want them split back into separate patches.
>
> > !   /* Same loop iteration.  */
> > !   if (dist == 0)
> > !     {
> > !       if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS, LOOP_LOC
> > (loop_vinfo)))
> > !       fprintf (vect_dump, "dependence distance 0.");
> > !       return false;
> > !     }
>
> return true?

zero distance is ok for vectorization. This function returns true
iff dependence exist such that it prohibits vectorization.

> > ! unsigned int loops_num;
>
> What is this?

I am just moving this from tree-vectorizer.c to tree-vectorizer.h
It holds number of loops in this function at the beginning of  
vectorization.
I'll add comments here.

> > *************** rs6000_emit_vector_select (rtx dest, rtx
> > *** 10667,10673 ****
> >
> >     t = gen_rtx_fmt_ee (SET, VOIDmode, temp,
> >                       gen_rtx_fmt_Ei (UNSPEC, dest_mode,
> > !                                     gen_rtvec (3, op1, op2, mask),
> >                                       vsel_insn_index));
> >     emit_insn (t);
> >     emit_move_insn (dest, temp);
> > --- 10667,10673 ----
> >
> >     t = gen_rtx_fmt_ee (SET, VOIDmode, temp,
> >                       gen_rtx_fmt_Ei (UNSPEC, dest_mode,
> > !                                     gen_rtvec (3, op2, op1, mask),
> >                                       vsel_insn_index));
>
> I don't have enough context to know whether this is correct,
> but you should pass this separately though an rs6000 maintainer.

OK. It was supplying operands in wrong order to vector select
instruction. When I posted patch for rs6000_emit_vector_select (),
test case only checked compilation. Obviously it did not catch the  
change
of behavior in vectorized loop because of this bug.

> > + /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -
> > maltivec" { target powerpc*-*-* } } */
> > + /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-stats -
> > msse2" { target i?86-*-* x86_64-*-* } } */
>
> Surely you're looking for another effective-target hook?

I just need to use same new check_effective_target_vect_condition hook.
Somehow, I missed it in this example.


Thanks,
-
Devang