Re: [PATCH] Handle vector COND_EXPRs in vector genericization (PR tree-optimization/65427)

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Mar 16, 2015 at 07:15:59PM +0100, Richard Biener wrote:
> On March 16, 2015 5:21:02 PM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
> >On the following testcase, gimple LIM creates a vector COND_EXPR
> >(scalar
> >condition, vector lhs, rhs2 and rhs3), but if we don't have
> >corresponding
> >vector mode for it, we ICE trying to expand the BLKmode COND_EXPR, as
> >it is
> >unprepared for that.
> >
> >This patch lowers those (parallel or piecewise).
> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> OK.  Though maybe LIM should not create these for cost reasons? I also wonder if we should lower them to control flow?

Yeah, I've been thinking about teaching LIM not to do that if it is BLKmode.
But then found how many other spots create COND_EXPRs and thought I just
can't catch all of them.  But guess I can change LIM incrementally too.

I've also been thinking about lowering it to control flow, but only if it
couldn't be done in say two halves comparison as in the testcase.  I suppose
doing say 2 V4SImode COND_EXPRs would still be beneficial over control flow,
but if it is more than that (say 4 or 8+) it might be already better to just
expand it as a PHI.  But, as we don't create basic blocks in
tree-vect-generic.c right now, I thought it might be too much for stage4.

	Jakub