On Thu, Oct 8, 2015 at 12:00 AM, Jeff Law <l...@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? > Jeff > >
