Re: [PATCH] Partial combiner fix for vector conditions (PR rtl-optimization/87065)

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Aug 27, 2018 at 04:29:25AM -0500, Segher Boessenkool wrote:
> Hi Jakub,
> 
> On Mon, Aug 27, 2018 at 09:24:16AM +0200, Jakub Jelinek wrote:
> > This patch is just a partial fix, combine.c has lots of other code that was
> > written before vector modes were introduced and won't work well with them.
> 
> Yeah.  But somehow it works fine almost all of the time.  Maybe most
> things with vector are just not attempted at all?

Some of them not attempted at all (e.g. some code is guarded with a
comparison that something is == const0_rtx or similar, for vector modes that
would be never true).  Other spots aren't easily provable to never trigger, I
think it just doesn't trigger that often so nobody noticed yet.  Some
problems are in combine.c, others in simplify-rtx.c.

> > @@ -9335,6 +9335,7 @@ if_then_else_cond (rtx x, rtx *ptrue, rt
> >  
> >  	  if (COMPARISON_P (cond0)
> >  	      && COMPARISON_P (cond1)
> > +	      && SCALAR_INT_MODE_P (mode)
> >  	      && ((GET_CODE (cond0) == reversed_comparison_code (cond1, NULL)
> >  		   && rtx_equal_p (XEXP (cond0, 0), XEXP (cond1, 0))
> >  		   && rtx_equal_p (XEXP (cond0, 1), XEXP (cond1, 1)))
> 
> It would do this for float as well before.  Did that not work?  Or, you
> want !VECTOR_MODE_P instead?

This is for (comparison1 * something) op (comparison2 * something2),
and mode is the mode of the whole expression.  While comparison operands can
be floating, the result of the comparison will never be floating, it can
only be some integral (scalar or vector) mode.

Note, Richard has acked the patch and I've already committed it.

	Jakub