Re: Abort in redirect_edge_and_branch on vax at line 866

[Jan Hubicka <jh at suse dot cz>]

> Let me be very clear, I was never happy with the fact that I had gcse leave
> an invalid insn in the stream, but at the time I couldn't find a way around
> the problem.  In retrospect I should have zapped the nop jump in gcse.c
> internal cleanup pass rather than depending on something external to
> gcse.c to clean it up.
I understans your point, but still don't see any purpose why the insn can
not be deleted, I will try to dig in more.
> 
>   > Would you preffer to change the code to run the delete_trivial_dead_insns
>   > and not delete the insn instead?
> If we can safely delete the nop jump, then I'd prefer to do that.  I think
> that's a better design.
> 
>   > (dleting trivially dead insns is probably something that really should
>   > happen,
> Possibly.  The question (of course) is whether or not there's anything
> generally useful for it to clean up?  It should be fairly easy to instrument
The copy propagation generally creates insns that are deletable and thus
delete_trivially_dead_insns after gcse deletes about 200 insns in the combine.i
compilation.
It does not make any difference on the resulting code tought - I guess because
with expensive_optimizations flags the cleanup_cfg together with
delete_trivially_dead_insns is called bit later after CSE.

We also do have delete_noop_moves from flow.c to do similar trick, but that
won't catch the cprop leftouts.
Honza
> delete_trivially_dead_insns to report back how many insns it removed.  Then
> you just have to build something reasonable (say the compiler itself) to 
> see how many things it deletes when it runs after gcse.
> 
> jeff