Re: cfgrtl

[Jan Hubicka <jh at suse dot cz>]

>  In message <20020204191500.GF26798@atrey.karlin.mff.cuni.cz>, Jan Hubicka 
> writes
>  > This should be removed by delete_dead_jumptables in flow.c.
> That only happens when we're doing life analysis -- which we do not do every
> time we optimize the CFG.
> 
> 
>  > At time of implementing try_redirect_edge_and_branch, the idea of deleting
>  > tablejump when existing instruction still may reference it looked very
>  > curious, so thats why it is in the code.
> Huh?  I don't follow.
> 
> The code in question is replacing a "complicated" jump with a simple jump.  It
> does so by first emitting the simple jump, then it deletes the complicated
> jump via delete_insn_chain.

Problem is that our tablejump instructions often uses different instructions
to compute the address and just mentioned the table in (use "table")
so after the tablejump is killed, the instructions still remains in the
stream.  Original code handled it by delete_computation call that killed
the related instructions in majority cases too, but new code don't do that
as it is considered good idea to keep the job on stand alone pass to kill
dead code (currently delete_trivially_dead_insns or liveness analysis does
so). Thats why the actual removal of jumptable is postnoted to after
liveness analysis when it should be finally dead.

Some targets reffers jumptable from const pool that makes the jumptable
actually kept in the insn stream and outputs it to file in the old
implementation, our new implementation behaves same way, but your patch 
changes the behaviour.

I don't think it is bad change, I just run into troubles when I did it
first time so thats why I choosed the other approach. Perhaps now after
all the cleanups and death of old jump code we are ready to do the
removal early.

Honza
> 
> This leaves an unreferenced label and jump table in the insn stream that will
> not be removed by any of the code in cfg*.c because the dead instructions
> are actually outside basic blocks (remember, the label and jump table are
> not in any basic block, they sit between basic blocks).  My patch removes
> the label & jump table after the only reference to them is removed.
> 
>  > One of drawbacks of your sollution is the fact that we will create
>  > DELETED_LABEL note during delete_insn_chain that will not be elliminated
>  > and remaing in the soutput sequence.
> That shouldn't be a significant problem.  It's certainly less of a problem
> than having an unreferenced jump table in the stream which in turn references
> labels that were removed from the stream (on the assumption the unused jump
> table would be removed).
> 
> jeff