[PATCH] Fix PR27151, ICE on valid with -ftree-vectorize

Richard Guenther rguenther@suse.de
Thu Apr 27 14:18:00 GMT 2006

On Thu, 27 Apr 2006, Roger Sayle wrote:

> On Thu, 27 Apr 2006, Richard Guenther wrote:
> > 2006-04-27   Richard Guenther  <rguenther@suse.de>
> >
> > 	PR tree-optimization/27151
> > 	* tree-vect-transform.c (vectorizable_condition): Punt on
> > 	values that have a different type than the condition.
> >
> > 	* gcc.dg/vect/pr27151.c: New testcase.
> Hmmm.  I agree that this patch disables the problematic vectorizations,
> and may be the most suitable fix for the 4.1 branch, but I believe the
> intention is to be able to optimize codes such as those in this test
> case.  The VEC_COND_EXPR tree code isn't documented in c-tree.texi,
> but I think a reasonable set of constraints is for it to behave much
> like a regular COND_EXPR, where the type of the condition needs not
> match the types of the other two operands.  Though for vectors they
> clearly need to have the same length.
> I believe that one source of these problems may be the line:
>   /* Arguments are ready. create the new vector stmt.  */
>   vec_compare = build2 (TREE_CODE (cond_expr), vectype,
>                         vec_cond_lhs, vec_cond_rhs);
> where perhaps this should build a node of type TREE_TYPE (vec_cond_lhs),
> instead of vectype.  In this case, vectype is V4SF, whilst hopefully
> vec_cond_lhs is V4SI or V4QI (though I've not investigated myself)?

>From my investigation there is only the V4SF type at all.  It looks like
it is tied to the stmt:

  tree vectype = STMT_VINFO_VECTYPE (stmt_info);

and only handles one type per stmt, while for this statement,

  floattmp = (int == 1) ? 0.0 : 1.0;

there are two types involved.  The VINFO struct only has

  /* The vector type to be used.  */
  tree vectype;

so it doesn't look like vectorization of COND_EXPRs has suitable
infrastructure in general.  Though it will obviously work for
integer vectors or floating point test conditions.

Maybe somebody from the vectorization maintainers can comment.  But
I also think this should be a safe fix for 4.1.


More information about the Gcc-patches mailing list