This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Update assertion in sched-ebb.c to cope with table jumps
- From: Jeff Law <law at redhat dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: David Malcolm <dmalcolm at redhat dot com>, Alexander Monakov <amonakov at ispras dot ru>, Andrey Belevantsev <abel at ispras dot ru>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 26 Mar 2019 12:15:26 -0600
- Subject: Re: [PATCH] Update assertion in sched-ebb.c to cope with table jumps
- References: <alpine.LNX.2.20.13.1901231642120.22415@monopod.intra.ispras.ru> <1548256275-42315-1-git-send-email-dmalcolm@redhat.com> <4ad1f9b7-343f-c1e2-3903-af6e43c2b611@redhat.com> <20190326175213.GP3969@gate.crashing.org>
On 3/26/19 11:52 AM, Segher Boessenkool wrote:
> On Mon, Mar 25, 2019 at 05:12:05PM -0600, Jeff Law wrote:
>> To touch on one of the issues I raised. AFAICT the schedulers don't use
>> SCHED_GROUP_P for dealing with tablejumps. They're used for
>> cc0-user/setter, fused insns and the like. That's a bit of a surprise.
>>
>> Given that the table isn't actually associated with the block with the
>> tablejump, SCHED_GROUP_P might actually create a whole new set of problems.
>>
>> Why oh why is the jump table data not actually attached to the tablejump
>> insn itself. Nearly 30 years of working on GCC and I can't answer that one.
>
> It somewhat makes sense for targets where the jump table is emitted in the
> text section; we then need to know its size for jumps over it, etc.
>
ISTM if you attach the table to the indirect jump, then you could
include the size of hte table in the size of the indirect jump on
targets where the table is emitted inline in the text section.
I don't think there's anything we're doing now that couldn't be done
with the table attached to the jump. I would even claim that some
things become notably easier :-)
But none of that is gcc-9 material.
jeff