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

[Roger Sayle <roger at eyesopen dot com>]

On Sat, 6 May 2006, Richard Guenther 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.
> ping!

After much research and investigation, you're right about the missing
infrastructure (though the actual blocker is deeper down than the issue
you described in your previous response), so the above patch is fine.
Ok for mainline and the 4.1 branch.


> > 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.


What I investigated was treating COND_EXPRs like reductions, which allow
multiple vector types in a single statement.  The trick is to avoid
using STMT_VINFO_VECTYPE in vect_get_vec_def_for_operand, and instead
use get_vectype_for_scalar_type, with an additional simple check that
the comparison operand's types are vectorizable in vect_is_simple_cond,
the middle-end does all the right things (resolving this ICE), and even
generates vectorized SSE code into the assembly output.

The problem is the optabs.  The way that the "vcond" optab is defined
by the backends, implicitly assumes that the type of the comparison
operands must be the same mode as the types of the VEC_COND_EXPR's
second and third arguments.  See for example, vcondsf4 and similar
named patterns in config/i386/i386.md.  This is all bogus, as internally
the x86 backend splits this into two sequences via ix86_expand_sse_cmp
and ix86_expand_sse_movcc, which would allow/support independent modes
between condition operands and results, if only the design of
conditional vectorization explicitly exposed vector masks that we
generated by vector comparisons, and consumed by vector conditional
moves.

Hence its the semantics of the backend/middle-end interface, via the
vcond optabs that forces this constraint, rather than the tree
representation or the middle-end itself.  This design flaw isn't
going to be fixed for 4.1 or 4.2, so your patch to simply avoid
attempting to vectorize the loop in the PR is appropriate.  It's
just unfortunate and disappointing that we're so close to being
able to vectorize this code on SSE.


Once you commit your patch and testcase to mainline, in addition
to closing PR27151 as a resolved regression, could you also open
another "missed-optimization" "enhancement" PR for mainline, and
include a link to PR27151?  That way we won't forget to come back
to this issue once we return to stage1.

Sorry again for the delay, and thanks for investigating this.

Roger
--