Re: cfgrtl

[law at redhat dot com]

In message <20020204225559.GC15683@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 > >  > If, by some accident, you suceed to elliminate  the tablejump very late
 > >  > (lets say after sched2 pass) and dead code removal is not done afterwar
 > ds,
 > >  > the computation remains in the stream. This is actally possible situati
 > on,
 > >  > as crossjumping is done after sched2 and sched2 may've reordered insns
 > >  > to make crossjumping realize that all arms of the tablejump are equival
 > ent.
 > > We can't allow this.  Ever.  
 > 
 > Hmm, perhaps we should simply prohibit the simplification after reload.
We probably need to prohibit it from the time life analysis finishes until
the end of compilation.

 > I can make patch to kill the delete_dead_jumptables and prohibit the
 > simplification tomorow. I am getting suck in modifying the genflags.h
 > for midlevel RTL, so I will probably take some sleep now.
Please slow down.  Let's deal with one issue at a time.  The first is what
to do about jump tables that are unreachable because their associated tablejump
is removed by the CFG simplifier early in the compiler.  I'd really prefer not
to go messing around with other (related) issues until we have settled the
initial debate.

 > Is it valid to call gen_jump after reload? Currently no code guards that but
 > perhaps we should, as at some platforms this may use temporary pseudo.
Unknown.



 > > Not exactly.  The jump table should *always* be attached to its associated
 > > tablejump insn.  That property should hold through the entire compilation,
 > > not just during the generic RTL phases.
 > 
 > True, but better in midRTL than never.
No.  This is the kind of change that should go in separately from generic
RTL.  In fact, it should go in before the generic RTL changes.  It's clearly
a small, independent cleanup of our IR.

jeff