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). I have tried to handle things in expand, but it is a) ugly and b) caused problems all over the place. I wonder if anyone can still modify any of the expander code, sigh -- lots of rope there, and it's a maze. ifcvt already has a lot of that "if we made a bad insn, back out", so it fits well here. This patch also is much less risky. Segher
