This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -ftree-vectorize can't vectorize plus?
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: "Daniel Berlin" <dberlin at dberlin dot org>
- Cc: gcc at gcc dot gnu dot org, "Rask Ingemann Lambertsen" <rask at sygehus dot dk>
- Date: Mon, 11 Sep 2006 22:00:13 +0300
- Subject: Re: -ftree-vectorize can't vectorize plus?
"Daniel Berlin" <dberlin@dberlin.org> wrote on 11/09/2006 06:27:16 PM:
> On 9/11/06, Dorit Nuzman <DORIT@il.ibm.com> wrote:
> > > A silly little testcase which the vectorizer doesn't vectorize:
> > >
> > ....
> > > autovecttest.c:11: note: not vectorized: relevant stmt not
> > > supported: D.1861_9 = (signed char) D.1860_8
> >
> > Can these type casts (from uchar to schar and back) be cleaned away by
some
> > pass before vectorization,
>
> Uh, what do you mean "cleaned away"?
> You can't just legally ignore them, they are changing the overflow
behavior.
not in the case of xor... I was referring to cases like in the pattern I
showed, in which the arguments are cast from unsigned to signed just to
perform the xor operation, and the result is cast back to unsigned. Isn't
this:
unsigned char D.1932
unsigned char D.1936
unsigned char D.1939
....
D.1933_9 = (signed char) D.1932_8;
D.1937_17 = (signed char) D.1936_16;
D.1938_18 = D.1937_17 ^ D.1933_9;
D.1939_19 = (unsigned char) D.1938_18;
the same as this?:
D.1939_19 = D.1936_16 ^ D.1932_8
dorit