cfgrtl

[Jan Hubicka]

>  > If, by some accident, you suceed to elliminate  the tablejump very late
>  > (lets say after sched2 pass) and dead code removal is not done afterwards,
>  > the computation remains in the stream. This is actally possible situation,
>  > as crossjumping is done after sched2 and sched2 may've reordered insns
>  > to make crossjumping realize that all arms of the tablejump are equivalent.
> We can't allow this.  Ever.  

Hmm, perhaps we should simply prohibit the simplification after reload.
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.

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.
> 
>  > > You absolutely can't leave the jump table in the stream if you remove its
>  > > associated tablejump insn.  This is doubly true if you've removed the
>  > > labels referenced by the jump table (as happens with the current sources
>  > > if you don't have my change).
>  > 
>  > It should not happen, they should get converted to NOTE_INSN_DELETED_LABEL a
>  > s well.
> It does happen.  You can see it very clearly from my example.
> 
>  > > In an ideal world we would attach the jump table to the tablejump itself w
>  > hich
>  > > would cause the jump table to automatically go away if we delete the table
>  > jump
>  > > insn.
>  > 
>  > We can undo the design mistakes at least partially in midrtl now...
> 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.
> 
> jeff