On Thu, Oct 8, 2015 at 12:00 AM, Jeff Law <law@redhat.com> wrote:
On 10/07/2015 02:26 AM, Richard Biener wrote:
Hmm, other passes avoid all this by not removing edges or blocks
themselves but leaving that to cfgcleanup. They simply replace the
condition in GIMPLE_CONDs or the switch value in GIMPLE_SWITCHes and
let cleanup_control_expr_graph do the hard part of the job.
Now - I don't know how that would interact with jump threads
covering those paths, that is, what kind of "mess" jump threading
would produce with the conditions/switches mangled that way.
The other nice thing is that CFG cleanup properly deals with loop
structure changes.
Threading will handle it correctly as that's essentially how we handled it
until last week ;-)
The "problem" is the threader thread through those blocks. And while that
works correctly, it is quite wasteful in terms of compile time and memory
consumption due to the block duplication required to preserve side effects.
It also churns the blocks & ssa-names used in the isolated regions which
makes comparing debugging dumps before/after threading much harder than it
ought to be.
Yes, but as you remove jump threading paths you could leave the CFG change to
cfg-cleanup anyway? To get better behavior wrt loop fixup at least?