Abort in redirect_edge_and_branch on vax at line 866
Jan Hubicka
jh@suse.cz
Thu Jan 10 08:09:00 GMT 2002
> 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
More information about the Gcc-bugs
mailing list