Patchwork [mips] Fix for PR target/56942

login
register
mail settings
Submitter Steven Bosscher
Date May 29, 2013, 10:15 p.m.
Message ID <CABu31nNf=6n32=ZLeGxBhomHA5__WWDAeWLHKOGuNACR_7jQgw@mail.gmail.com>
Download mbox | patch
Permalink /patch/247418/
State New
Headers show

Comments

Steven Bosscher - May 29, 2013, 10:15 p.m.
On Tue, May 28, 2013 at 10:39 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Hi Steven,
>>
>> Steven Bosscher <stevenb.gcc@gmail.com> writes:
>>> Imho the active-insn "idiom" is the best solution for the moment. I
>>> will fix this mess properly asap, probably next week.
>>
>> Just wondering, how are things going with this?  (I assume fixing it
>> properly means getting rid of the FIXME in next_active_insn?)
>
> Yes, it involves getting this to work:


And I can't get it to fail. I also can't find any place where the
label and jump table might get separated. I was expecting some trouble
with cross-jumping but it seems that it takes care of updating the
label reference, and skip_insns_after_block already expects the label
and table to be adjacent.

So let's just see if/what breaks...

Bootstrapped&tested on powerpc64-unknown-linux-gnu (unix{,-m32}).
Bootstrapped&tested on x86_64-unknown-linux-gnu (unix{,-m32}).
Build&tested powerpc64 X mips-elf.

OK for trunk?

If it causes any trouble, please file a PR and assign it to me.

And when the dust has settled, I can clean up the FIXME for
JUMP_TABLE_DATA in next_active_insn, and fix up the back ends.

Ciao!
Steven


      * rtlanal.c (tablejump_p): Expect table and label to be adjacent.
Eric Botcazou - May 30, 2013, 7:10 a.m.
> And I can't get it to fail. I also can't find any place where the
> label and jump table might get separated. I was expecting some trouble
> with cross-jumping but it seems that it takes care of updating the
> label reference, and skip_insns_after_block already expects the label
> and table to be adjacent.

As well as inside_basic_block_p and delete_dead_jumptables.

> So let's just see if/what breaks...
> 
> Bootstrapped&tested on powerpc64-unknown-linux-gnu (unix{,-m32}).
> Bootstrapped&tested on x86_64-unknown-linux-gnu (unix{,-m32}).
> Build&tested powerpc64 X mips-elf.
> 
> OK for trunk?

Yes, but I'd go one step farther and replace next_active_insn with NEXT_INSN 
in tablejump_p; however it's your call.
Steve Ellcey - May 30, 2013, 2:53 p.m.
On Thu, 2013-05-30 at 00:15 +0200, Steven Bosscher wrote:

> And I can't get it to fail. I also can't find any place where the
> label and jump table might get separated. I was expecting some trouble
> with cross-jumping but it seems that it takes care of updating the
> label reference, and skip_insns_after_block already expects the label
> and table to be adjacent.
> 
> So let's just see if/what breaks...
> 
> Bootstrapped&tested on powerpc64-unknown-linux-gnu (unix{,-m32}).
> Bootstrapped&tested on x86_64-unknown-linux-gnu (unix{,-m32}).
> Build&tested powerpc64 X mips-elf.

I tested this with mips-mti-linux-gnu and mips-mti-elf by building cross
compilers and testing and I did not hit the assert either.

Steve Ellcey
sellcey@imgtec.com

Patch

Index: rtlanal.c
===================================================================
--- rtlanal.c   (revision 199324)
+++ rtlanal.c   (working copy)
@@ -2711,6 +2711,7 @@  tablejump_p (const_rtx insn, rtx *labelp, rtx *tab
       && (table = next_active_insn (label)) != NULL_RTX
       && JUMP_TABLE_DATA_P (table))
     {
+      gcc_assert (table == NEXT_INSN (label));
       if (labelp)
        *labelp = label;
       if (tablep)