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
On 1/24/19 2:10 PM, Segher Boessenkool wrote:
> On Thu, Jan 24, 2019 at 06:43:38PM +0300, 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 anticipat
On 1/24/19 3:10 PM, Eric Botcazou wrote:
>> md.texi says
>>
>> The @samp{tablejump} insn is always the last insn before the jump
>> table it uses. Its assembler code normally has no need to use the
>> second operand, but you should incorporate it in the RTL pattern so
>> that the jump optimizer wi
On 1/23/19 6:52 AM, Alexander Monakov wrote:
> On Wed, 23 Jan 2019, Andrey Belevantsev wrote:
>
>> For that, I'm not sure. Your patch will leave the tablejump unscheduled at
>> all, i.e. any fields like INSN_TICK would be unfilled and thus the later
>> passes like bundling on ia64 will not work.
On 1/23/19 12:29 PM, Segher Boessenkool wrote:
> On Wed, Jan 23, 2019 at 04:52:24PM +0300, Alexander Monakov wrote:
>> On Wed, 23 Jan 2019, Andrey Belevantsev wrote:
>>> For that, I'm not sure. Your patch will leave the tablejump unscheduled at
>>> all, i.e. any fields like INSN_TICK would be unfi
On 2/18/19 10:41 AM, Alexander Monakov wrote:
> On Mon, 18 Feb 2019, Aaron Sawdey wrote:
>
>> 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 ye
On Mon, 18 Feb 2019, Aaron Sawdey wrote:
> 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 8
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 t
> md.texi says
>
> The @samp{tablejump} insn is always the last insn before the jump
> table it uses. Its assembler code normally has no need to use the
> second operand, but you should incorporate it in the RTL pattern so
> that the jump optimizer will not delete the table as unreachable code.
>
On Thu, Jan 24, 2019 at 06:43:38PM +0300, 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
> >
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 nee
On Wed, Jan 23, 2019 at 04:52:24PM +0300, Alexander Monakov wrote:
> On Wed, 23 Jan 2019, Andrey Belevantsev wrote:
> > For that, I'm not sure. Your patch will leave the tablejump unscheduled at
> > all, i.e. any fields like INSN_TICK would be unfilled and thus the later
> > passes like bundling o
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
On Wed, 23 Jan 2019, Andrey Belevantsev wrote:
> For that, I'm not sure. Your patch will leave the tablejump unscheduled at
> all, i.e. any fields like INSN_TICK would be unfilled and thus the later
> passes like bundling on ia64 will not work. Maybe we can just stop
> tablejumps from moving wit
Hi David,
On 18.01.2019 19:58, David Malcolm wrote:
> On Fri, 2019-01-18 at 12:32 -0500, David Malcolm wrote:
>
> [CCing Abel]
>
>> PR rtl-optimization/88423 reports an ICE within sched-ebb.c's
>> begin_move_insn, failing the assertion at line 175, where there's
>> no fall-through edge:
>>
>> 17
On Fri, Jan 18, 2019 at 5:43 PM David Malcolm wrote:
> (1) What does GCC mean by "ebb" in this context?
In this context, the EBB is what Muchnick would call a trace.
Ciao!
Steven
On 1/18/19 10:32 AM, David Malcolm wrote:
> PR rtl-optimization/88423 reports an ICE within sched-ebb.c's
> begin_move_insn, failing the assertion at line 175, where there's
> no fall-through edge:
>
> 171 rtx_insn *x = NEXT_INSN (insn);
> 172 if (e)
> 173 gcc_checking_as
On Fri, 2019-01-18 at 12:32 -0500, David Malcolm wrote:
[CCing Abel]
> PR rtl-optimization/88423 reports an ICE within sched-ebb.c's
> begin_move_insn, failing the assertion at line 175, where there's
> no fall-through edge:
>
> 171 rtx_insn *x = NEXT_INSN (insn);
> 172 if (e)
>
PR rtl-optimization/88423 reports an ICE within sched-ebb.c's
begin_move_insn, failing the assertion at line 175, where there's
no fall-through edge:
171 rtx_insn *x = NEXT_INSN (insn);
172 if (e)
173 gcc_checking_assert (NOTE_P (x) || LABEL_P (x));
174 else
175
19 matches
Mail list logo
