On Wed, 23 Jan 2019, Alexander Monakov wrote:
> That said, I'm really concerned that on this testcase we should not be moving
> the tablejump *at all*: we are moving it up past a 'use ax' insn (the use is
> for the function's return value). So after the move the use is in an
> unreachable
> block, which makes no sense.
>
> So my concern is that just fixing the assert changes the issue from the ICE
> to a
> (latent) wrong-code issue.
>
> There should have been an anti-dependence between the use and the jump. I'll
> try
> to investigate.
It appears that sched-deps tries to take notice of a barrier after a jump, but
similarly to sched-ebb doesn't anticipate that for a tablejump the barrier will
appear after two more insns (a code_label and a jump_table_data).
If so, it needs a fixup just like the posted change for the assert. I'll fire up
a bootstrap/regtest.
Alexander
* sched-deps.c (sched_analyze_insn): Take into account that for
tablejumps the barrier appears after a label and a jump_table_data.
--- a/gcc/sched-deps.c
+++ b/gcc/sched-deps.c
@@ -3005,6 +3005,8 @@ sched_analyze_insn (struct deps_desc *deps, rtx x,
rtx_insn *insn)
if (JUMP_P (insn))
{
rtx_insn *next = next_nonnote_nondebug_insn (insn);
+ if (LABEL_P (next) && JUMP_TABLE_DATA_P (NEXT_INSN (next)))
+ next = NEXT_INSN (NEXT_INSN (next));
if (next && BARRIER_P (next))
reg_pending_barrier = MOVE_BARRIER;
else
