------- Comment #4 from rguenther at suse dot de 2008-09-14 10:36 -------
Subject: Re: [4.4 Regression] Revision 140257 causes
vectorizer tests failures
On Sun, 14 Sep 2008, irar at il dot ibm dot com wrote:
>
>
> ------- Comment #3 from irar at il dot ibm dot com 2008-09-14 10:04 -------
> (In reply to comment #2)
> > I don't follow. For vectorize2.c we have
> >
> > b[i] = lrint (a[i]);
> >
> > where we should be able to vectorize this using lrint vectorization and
> > a scalar long -> int conversion (which is a no-op on i686 and should be
> > vectorized on x86_64). There is no aliasing issue involved here.
>
> I am working on x86_64 using -m32 (without -m32 I get
> ../../gcc.target/i386/vectorize2.c:15: note: function is not vectorizable.
> ../../gcc.target/i386/vectorize2.c:15: note: not vectorized: relevant stmt not
> supported: D.1603_6 = lrint (D.1602_5); ).
>
> I don't see any conversion:
Indeed, the conversion is for the 64bit case:
D.1614_6 = lrint (D.1613_5);
D.1615_7 = (int) D.1614_6;
but yes, we cannot vectorize lrint if the result is 64bit long
(which it is on 64bit).
For the 32bit case the problem is really the choice of the vector
type for the store (where is this decided on?). As the type of
b is int it should have chosen vector int instead of vector long.
Note that it is perfectly valid (on 32bit) to assign a vector long
to a vector int. So with a change like
> The vectorized version (if the alias check is removed) is:
> ...
> vector long int * ivtmp.120;
vector int * ivtmp.120;
> vector long int vect_var_.113;
> ...
>
> vect_var_.111_20 = *ivtmp.110_18;
> ivtmp.110_21 = ivtmp.110_18 + 16;
> vect_var_.112_22 = *ivtmp.110_21;
> vect_var_.113_23 = __builtin_ia32_vec_pack_sfix (vect_var_.111_20,
> vect_var_.112_22);
> *ivtmp.120_26 = vect_var_.113_23;
>
> The alias check is for the store, checking *ivtmp.120_26 and b.
the alias check would be fine.
So,
/* The type of the vector store is determined by the rhs. */
vectype = get_vectype_for_scalar_type (TREE_TYPE (op));
the type should be determined by the lhs (after all we try to check
if the new vector lhs aliases the old scalar lhs). But of course
this means the vector lhs type should be chosen to actually match
the scalar type of the lhs.
if (!useless_type_conversion_p (TREE_TYPE (op), TREE_TYPE
(scalar_dest)))
{
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, "operands of different types");
return false;
}
This test should then be adjusted to check
if (!useless_type_conversion_p (TREE_TYPE (TREE_TYPE
(vectype)), TREE_TYPE (op)))
first, it was the wrong way around, second we should check if the
conversion from the rhs (op) to the element type of the lhs
vector type (vectype) is useless.
Now the interesting part is of course where we select the type
for the induction variable for the store (I can't find this
atm).
Hope this helps,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37491
