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