On Wed, 23 Jan 2019, Alexander Monakov wrote:
> 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.
Updated patch below (now taking into account that NEXT_INSN may give NULL)
passes bootstrap/regtest on x86_64, also with -fsched2-use-superblocks.
I'm surprised to learn that a tablejump may be not the final insn in its
containing basic block. It certainly seems like a ripe ground for logic
bugs like this one. Is it really intentional?
OK for trunk?
Thanks.
Alexander
PR rtl-optimization/88347
PR rtl-optimization/88423
* 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,11 @@ sched_analyze_insn (struct deps_desc *deps, rtx x,
rtx_insn *insn)
if (JUMP_P (insn))
{
rtx_insn *next = next_nonnote_nondebug_insn (insn);
+ /* ??? For tablejumps, the barrier may appear not immediately after
+ the jump, but after a label and a jump_table_data insn. */
+ if (next && LABEL_P (next) && NEXT_INSN (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
