This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423)
- From: Jeff Law <law at redhat dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>, Andrey Belevantsev <abel at ispras dot ru>
- Cc: David Malcolm <dmalcolm at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 25 Mar 2019 17:34:27 -0600
- Subject: Re: [PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423)
- References: <1547832768-62740-1-git-send-email-dmalcolm@redhat.com> <1547830690.7788.176.camel@redhat.com> <4a8b4249-1aa4-92ff-9497-ef17d8f64b80@ispras.ru> <alpine.LNX.2.20.13.1901231642120.22415@monopod.intra.ispras.ru> <alpine.LNX.2.20.13.1901231902500.22415@monopod.intra.ispras.ru> <alpine.LNX.2.20.13.1901241832160.22415@monopod.intra.ispras.ru>
On 1/24/19 8: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.
I merged this with David's new tests and committed the changes to the trunk.
THanks,
Jeff