This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]