Re: PATCH: Re: ICE in 920624-1.c with -O3 -funroll-loops on

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> 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.

That's what my first patch did.  However, Honza pointed out that it
is valid for a case pattern to appear to use the jump table but in
fact do an indirect branch using a pointer.  If you kill the jump
table, then you need to kill the jumps first and they are difficult
to locate.  However, this does not apply to the VAX and I believe
the jump table can be safely deleted.

My current proposal essentially creates for the VAX the same situation
as we currently have on the PA (ie., the jump table remains around
until removed by dead code analysis).  Obviously, not as nice as
your suggestion below but it seems to work.

The situations where a switch gets folded are relatively rare.  Loop
unrolling is where I first noted the problem.  Thus, unless you are
aware of other bugs affected by this problem, I would defer a better
fix until after 3.1 branches.

The current patch only affects the VAX because it is the only port
that defines CASE_DROPS_THROUGH, and thereby the only port where the
case insn is folded to a jump directed to the label before the jump table.
Thus, I don't believe patch will affect any other port.

> 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.

Sounds wonderful.  In thinking about this, it became clear that separating
these components was just asking for trouble.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)