https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85408
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This is a complete mess.
bb-reorder.c has fix_crossing_unconditional_branches for targets that don't
define HAS_LONG_UNCOND_BRANCHES to true.
One thing which isn't clear is if it is right that these branches have
JUMP_LABEL attached to them. If not, then e.g.
--- gcc/bb-reorder.c.jj 2018-04-13 21:49:36.000000000 +0200
+++ gcc/bb-reorder.c 2018-04-16 11:18:33.328681163 +0200
@@ -2178,7 +2178,7 @@ fix_crossing_unconditional_branches (voi
label = JUMP_LABEL (last_insn);
label_addr = gen_rtx_LABEL_REF (Pmode, label);
- LABEL_NUSES (label) += 1;
+ LABEL_NUSES (label)++;
/* Get a register to use for the indirect jump. */
@@ -2187,7 +2187,8 @@ fix_crossing_unconditional_branches (voi
/* Generate indirect the jump sequence. */
start_sequence ();
- emit_move_insn (new_reg, label_addr);
+ rtx_insn *last = emit_move_insn (new_reg, label_addr);
+ add_reg_note (last, REG_LABEL_OPERAND, label);
emit_indirect_jump (new_reg);
indirect_jump_sequence = get_insns ();
end_sequence ();
@@ -2210,9 +2211,6 @@ fix_crossing_unconditional_branches (voi
emit_insn_before (indirect_jump_sequence, last_insn);
delete_insn (last_insn);
- JUMP_LABEL (jump_insn) = label;
- LABEL_NUSES (label)++;
-
/* Make BB_END for cur_bb be the jump instruction (NOT the
barrier instruction at the end of the sequence...). */
fixes this ICE. Another thing is that these indirect jumps are shortly
afterwards "optimized" into direct jumps anyway, even without the above patch
with the same testcase e.g. without -fmodulo-sched option, with the patch even
with that option. The thing is, with hot/cold partitioning we don't really
know how far from each other the hot and cold partitions will be. On PowerPC
the direct branch is I think 26-bit (with bottom two bits assumed to be 0 and
reused for some flags) and thus considered insufficient. x86_64 in the default
model has both conditional and unconditinal jumps with signed 32-bit immediates
and thus considered ok.
So, no matter whether we emit the JUMP_LABEL or not on the indirect jump, we
should also make sure we don't turn those indirect jumps into direct jumps if
they are crossing and !HAVE_LONG_UNCOND_BRANCH.
Lastly, HAVE_LONG_UNCOND_BRANCH true is probably not ok for x86_64
-mcmodel=large.
Honza, thoughts on this?
