[PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423)

Aaron Sawdey acsawdey@linux.ibm.com
Mon Feb 18 16:30:00 GMT 2019


The code in emit_case_dispatch_table() will very clearly always emit branch/label/jumptable_data/barrier
so this does need to be handled. So, yes tablejump always looks like this, and also yes it seems to be
ripe ground for logic bugs, we have 88308, 88347, 88423 all related to it.

In the long term it might be nice to use a general mechanism (SCHED_GROUP_P?) for handling the label and jump
table data that follow a case branch using jump table.

But for now in stage 4, I think the right way to fix this is with the patch that Segher posted earlier.
If regtest passes (x86_64 and ppc64/ppc32), ok for trunk?

2019-02-18  Aaron Sawdey  <acsawdey@linux.ibm.com>

	PR rtl-optimization/88347
	* schedule-ebb.c (begin_move_insn): Apply Segher's patch to handle
	a jump table before the barrier.


On 1/24/19 9:43 AM, Alexander Monakov wrote:
> 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
> 

-- 
Aaron Sawdey, Ph.D.  acsawdey@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain



More information about the Gcc-patches mailing list