On Wed, Mar 18, 2015 at 03:10:44PM +0000, Kyrill Tkachov wrote:
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.
The testcase ICEs on arm-none-eabi at -Os (only):
0x7e6f11 process_insert_insn
$TOP/gcc/gcse.c:2174
0x7e8a80 insert_insn_end_basic_block
$TOP/gcc/gcse.c:2196
0x7eab01 hoist_code
$TOP/gcc/gcse.c:3492
0x7eab01 one_code_hoisting_pass
$TOP/gcc/gcse.c:3722
0x7eab01 execute_rtl_hoist
$TOP/gcc/gcse.c:4212
0x7eab01 execute
$TOP/gcc/gcse.c:4293
Must be some unrelated latent issue, either in arm backend or in gcse.
I think the lowering I've done could be very easily just present in user
code, so shouldn't be that hard to adjust the testcase so that it ICEs
already before the commit.