http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938
--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-10-16 21:22:02
UTC ---
(In reply to comment #4)
> >
> > In emit_cmp_and_jump_insn_1, the line
> >
> > gcc_assert (!find_reg_note (insn, REG_BR_PROB, 0));
> >
> > blows up, because of config/sh/sh.c (expand_cbranchsi4):
> >
> > rtx jump = emit_jump_insn (branch_expander (operands[3]));
> > if (probability >= 0)
> > add_reg_note (jump, REG_BR_PROB, GEN_INT (probability));
>
> I am confused why this code causes the assert in emit_cmp_and_jump_insn_1.
Summary: The backend attaches REG_BR_PROB notes when it expands cbranch
patterns. The assumption in emit_cmp_and_jump_insn_1 is that no such notes
have been attached yet.
> Could you please attach a stack trace?
A simplified stack trace:
../../../srcw/libgcc/fp-bit.c: In function '__unpack_d':
../../../srcw/libgcc/fp-bit.c:442:1: internal compiler error: in
emit_cmp_and_jump_insn_1, at optabs.c:4275
0x847036a emit_cmp_and_jump_insn_1
../../gcc-trunk-van/gcc/optabs.c:4275
0x847036a emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
../../gcc-trunk-van/gcc/optabs.c:4326
0x826e167 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_def*, rtx_def*, int)
../../gcc-trunk-van/gcc/dojump.c:1072
0x826f680 do_jump(tree_node*, rtx_def*, rtx_def*, int)
../../gcc-trunk-van/gcc/dojump.c:591
0x8271a87 jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_def*, int)
../../gcc-trunk-van/gcc/dojump.c:116
0x8211433 expand_gimple_cond
../../gcc-trunk-van/gcc/cfgexpand.c:1850
0x8219a47 expand_gimple_basic_block
../../gcc-trunk-van/gcc/cfgexpand.c:3830
0x821b337 gimple_expand_cfg
../../gcc-trunk-van/gcc/cfgexpand.c:4475
... but it doesn't show where the REG_BR_PROB reg note comes from.
What happens is that 'emit_cmp_and_jump_insn_1' invokes 'emit_jump_insn' which
ends up expanding the cbranchsi4 insn in the backend's machine description. On
SH, the cbranchsi4 expander invokes expand_cbranchsi4 (in sh.c), which attaches
a REG_BR_PROB note.
In case of SImode cbranch, the probability is always set to -1 and
expand_cbranchsi4 does not attach a note. So no problem with this one.
However, when it comes to DImode cbranch (cbranchdi4), SH's expand_cbranchdi4
will split & expand the comparison into multiple SImode cbranch insns and
attach REG_BR_PROB notes to them. After that it returns to
emit_cmp_and_jump_insn_1 and the assert blows.
> If there is a REG_BR_PROB note already but the
> probability is different from what is passed to emit_cmp_and_jump_insn_1,
> should the existing value be replaced or left as such.
Hm, or maybe try to accumulate the probabilities in some useful way? In this
crashing case for the DImode comparison prob in emit_cmp_and_jump_insn_1 is
6100, and SH's expand_cbranchdi4 expands two cbranchsi4 insns, one with prob
'-1' (i.e. no reg note), and another one with '0'.
