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

[Richard Biener <rguenther at suse dot de>]

On March 16, 2015 7:26:58 PM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
>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.

Yeah, the patch is fine for stage 4.  I just wrote down my random thoughts.

Richard.

>	Jakub