Re: [patch] Fix PR tree-optimization/45902

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Oct 11, 2010 at 10:48 PM, Ira Rosen <IRAR@il.ibm.com> wrote:
>
>
> Richard Guenther <richard.guenther@gmail.com> wrote on 11/10/2010 04:03:07
> PM:
>
>>
>> On Mon, Oct 11, 2010 at 3:03 PM, Ira Rosen <IRAR@il.ibm.com> wrote:
>> > Richard Guenther <richard.guenther@gmail.com> wrote on 11/10/2010
> 02:32:08
>> > PM:
>> >
>> >>
>> >> On Mon, Oct 11, 2010 at 2:19 PM, Ira Rosen <IRAR@il.ibm.com> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > This patch fixes a bug in creation of a vector of constants in SLP.
> The
>> >> > problem is in the type of created vector. It should be set to the
>> > vector
>> >> > type of the statement unless it's a pointer.
>> >> >
>> >> > Bootstrapped and tested on x86_64-suse-linux and checked that the
>> > failure
>> >> > is fixed on powerpc64-suse-linux.
>> >> >
>> >> > Committed to mainline, ok for 4.5?
>> >>
>> >> I don't think this makes sense. ?If at all the selection of which type
>> >> to use should be based on the operation code and the operand
>> >> position, but not on CONSTANT_CLASS_P or pointer-type-ness.
>> >>
>> >> So - what operation code / operand position is currently mishandled?
>> >
>> > This function creates vectors of constants or loop invariants. If it's
> a
>> > variable (loop invariant), we know exactly the type, hence the check
> for
>> > CONSTANT_CLASS_P.
>> >
>> > I guess instead of checking the type we can check if it's
> POINTER_PLUS_EXPR
>> > to catch the cases where we need the operand's type instead of the
> stmt's
>> > vectype.
>> >
>> > Does this make sense?
>>
>> That makes more sense, with ...
>>
>> > Index: tree-vect-slp.c
>> > ===================================================================
>> > --- tree-vect-slp.c ? ? (revision 165302)
>> > +++ tree-vect-slp.c ? ? (working copy)
>> > @@ -1836,10 +1836,10 @@ vect_get_constant_vectors (slp_tree slp_
>> > ? VEC (tree, heap) *voprnds = VEC_alloc (tree, heap,
> number_of_vectors);
>> > ? bool constant_p, is_store;
>> > ? tree neutral_op = NULL;
>> > + ?enum tree_code code = gimple_assign_rhs_code (stmt);
>> >
>> > ? if (STMT_VINFO_DEF_TYPE (stmt_vinfo) == vect_reduction_def)
>> > ? ? {
>> > - ? ? ?enum tree_code code = gimple_assign_rhs_code (stmt);
>> > ? ? ? if (reduc_index == -1)
>> > ? ? ? ? {
>> > ? ? ? ? ? VEC_free (tree, heap, *vec_oprnds);
>> > @@ -1895,18 +1895,14 @@ vect_get_constant_vectors (slp_tree slp_
>> > ? ? }
>> >
>> > ? if (CONSTANT_CLASS_P (op))
>> > - ? ?{
>> > - ? ? ?constant_p = true;
>> > - ? ? ?if (POINTER_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt))))
>> > - ? ? ? ?vector_type = get_vectype_for_scalar_type (TREE_TYPE (op));
>> > - ? ? ?else
>> > - ? ? ? ?vector_type = STMT_VINFO_VECTYPE (stmt_vinfo);
>> > - ? ?}
>> > + ? ?constant_p = true;
>> > ? else
>> > - ? ?{
>> > - ? ? ?constant_p = false;
>> > - ? ? ?vector_type = get_vectype_for_scalar_type (TREE_TYPE (op));
>> > - ? ?}
>> > + ? ?constant_p = false;
>> > +
>> > + ?if (code == POINTER_PLUS_EXPR)
>>
>> checking
>>
>> ? ? ? ? ? && op_num == 2
>
> But if it's the first operand then its type is the type of the stmt, i.e.,
> we get the same type anyway, right?

Yes.  So your patch looks ok, possibly with a comment that looking
at either operand is ok.

Thanks,
Richard.

> Thanks,
> Ira
>
>>
>> (with a possible fixup for the reduction case where that doesn't seem to
>> be prevailing).
>>
>> Thanks,
>> Richard.
>>
>> > + ? ?vector_type = get_vectype_for_scalar_type (TREE_TYPE (op));
>> > + ?else
>> > + ? ?vector_type = STMT_VINFO_VECTYPE (stmt_vinfo);
>> >
>> > ? gcc_assert (vector_type);
>> > ? nunits = TYPE_VECTOR_SUBPARTS (vector_type);
>> >
>> > Thanks,
>> > Ira
>> >
>> >
>> >
>
>