On 01/14/2017 10:11 PM, Segher Boessenkool wrote:
On Sat, Jan 14, 2017 at 09:23:45PM -0700, Jeff Law wrote:
But isn't this a backend failing? ISTM that gen_cond_trap just calls
standard expansion routines and they should either have generated a
valid sequence or NULL.
What in particular generated insn 64 and shouldn't it instead have
indicated a failure?
ifcvt calls gen_cond_trap which then calls prepare_cmp_insn, which then
calls prepare_operand on the two arms, which ends up as copy_to_mode_reg
IIRC. The instructions copy_to_mode_reg comes up with are *not* valid
machine insns; their RHS is ultimately given by what ifcvt called
gen_cond_trap with (the comparison of the *two* RHS together is a valid
instruction! -- well, a splitter; but there is no such trap insn).
So it's the setup bits done by prepare_cmp_insn that are the problem
and thus the test in gen_cond_trap isn't going to help. Ugh. AFAICT
prepare_cmp_insn, through a series of calls, ends up in emit_move_insn
which is just going to blindly emit the move and we've lost. Sigh.
OK. Let's go with your patch.
Thanks,
jeff
