PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on vax-dec-ultrix4.3

[law@redhat.com]

 In message <20020204164731.A19099@redhat.com>, Richard Henderson writes:
 > On Mon, Feb 04, 2002 at 05:35:52PM -0700, law@redhat.com wrote:
 > > Agreed.  As I mentioned, I'm extremely tempted to burn tonight and
 > > get rid of having a separate insn for the ADDR_VEC/ADDR_DIFF_VEC.
 > > 
 > > Thoughts?
 > 
 > If you can make it work, I'm all for it.
The only thing that makes it even a mildly interesting problem is the ports
that want to use the label before the tablejump for computations.

Attaching the jump table to the tablejump isn't all that difficult, but we
still have the fun and exciting job of dealing with that peksy code label --
with the downside that without the separate ADDR_VEC/ADDR_DIFF_VEC, it's
less clear that the label is "special".

What we could do in the short term is to delete the jump table when we
optimize the jump, but leave the CODE_LABEL alone.   That deals with the
immediate problem of needing to get unused jump tables out of the insn
stream.  By leaving the CODE_LABEL in the stream we avoid dangling
references in normal insns which used that label for computations.

I believe John's patch as well as mine could be easily adapted to such
a scheme.

--

Looking into the future, we need some way to have those pesky computation
insns reference a widget which is attached (along with the jump table) to
the tablejump insn.  [ The widget is a magic code label, of course. ]

By having all 3 key items (tablejump, jump table and magic code label) in a
single insn we avoid all the mess of knowing that magic items follow table
jumps which must be kept in specific orders, and we avoid having random crud
existing between basic blocks.

When doing final assembly output, we would first emit the jump, then emit
the magic label (if any), then the jump table (if any).


When we optimize a tablejump into a simple jump, we zero out the attached jump
table and emit the magic label into the insn stream as a normal CODE_LABEL (at
which point it behaves like any CODE_LABEL which is not referenced by a jumping
insn).

 > BTW, another edge case you should consider in doing this is
 > s390, which dumps the tablejump label into the constant pool.
 > I don't think there's an integrated sim for that one, but 
 > perhaps faking it via "ln -s /bin/true s390-linux-run" and
 > checking that the execute tests compile is a good enough 
 > sanity check.
I think we'd want to largely treat the s390 like the other ports; with the
caveat that we dump the table into the constant pool relatively late in
the compilation process.    ie, I'd like to present the optimizers with
a common model for dealing with tablejumps.

Thoughts?

jeff