Jakub Jelinek <jakub at gcc dot> changed:

           What    |Removed                     |Added
                 CC|                            |hubicka at gcc dot,
                   |                            |jakub at gcc dot

--- Comment #2 from Jakub Jelinek <jakub at gcc dot> ---
This is a complete mess.
bb-reorder.c has fix_crossing_unconditional_branches for targets that don't
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

Honza, thoughts on this?

Reply via email to