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

[law at redhat dot com]

In message <200202042337.g14NbDAV020955@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > > On Tue, Jan 15, 2002 at 06:16:14PM -0500, John David Anglin wrote:
 > > > This patch fixes the problem by deleting the jump table data when a
 > > > conditional or computed jump is converted to an unconditional jump.
 > > > I have verified that the patch fixes the original problem observed
 > > > under vax-dec-ultrix4.3.  A new vax bootstrap is underway but it
 > > > won't finish until sometime next month.
 > > 
 > > This is extremely delicate.  It is not uncommon for there to 
 > > be references remaining to the jump table that won't be deleted
 > > until later dead code elimination.
 > > 
 > > I'm therefore uncomfortable with simply removing it like this.
 > > I'm not sure what to suggest as an alternative though...
 > 
 > Does this look better?  The patch no longer removes the jump table.
 > It simply changes the branch destination to a new label following
 > the jump table when it detects that the target of the jump is the
 > following insn.  The subsequent flow analysis deletes the unused jump
 > table.  This should only happen on the vax.
 > 
 > Tested on vax-dec-ultrix4.3 and various PA builds for the last month.
 > 
 > OK?
 > 
 > Dave
 > -- 
 > J. David Anglin                                  dave.anglin@nrc.ca
 > National Research Council of Canada              (613) 990-0752 (FAX: 952-66
 > 05)
 > 
 > 2002-01-16	John David Anglin  <dave@hiauly1.hia.nrc.ca>
 > 
 > 	* cse.c (cse_insn): Fix the destination of unconditional jumps to an
 > 	immediately following code label, followed by jump table data.
I hate to interject myself into this conversation, but I think Richard is
wrong here.

If we convert a tablejump into a simpler jump, then we should (if at all
possible) remove the associated jump table.  Numerous unpleasant problems
arise if we leave an unreferenced jump table in the insn stream.

Or maybe we just bite the bullet right now, today and attach the jump
table to the jump itself.  I realize that we're rather late in the gcc-3.1
process, but we've clearly got a problem that needs to be addressed and
the various attempts at addressing it within the existing framework have
inevitably caused problems.  That tells me we need to fix the underlying
framework.

jeff