On 10/09/2015 09:45 AM, Jeff Law wrote:
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?
So go ahead and detect, remove the threading paths, but leave final
fixup to cfg-cleanup. I can certainly try that.
It'd actually be a good thing to experiement with regardless -- I've
speculated that removing the edges in DOM allows DOM to do a better job,
but never did the instrumentation to find out for sure. Deferring the
final cleanup like you've suggested ought to give me most of what I'd
want to see if there's really any good secondary effects of cleaning up
the edges in DOM.
So I started looking at this in response to 68619, where this approach
does indeed solve the problem.
Essentially DOM's optimization of those edges results in two irredicuble
loops becoming reducible. The loop analysis code then complains because
we don't have proper loop structures for the new natural loops.
Deferring to cfg_cleanup works because if cfg_cleanup does anything, it
sets LOOPS_NEED_FIXUP (which we were trying to avoid in DOM). So it
seems that the gyrations we often do to avoid LOOPS_NEED_FIXUP are
probably not all that valuable in the end. Anyway...
There's some fallout which I'm still exploring. For example, we have
cases where removal of the edge by DOM results in removal of a PHI
argument in the target, which in turn results in the PHI becoming a
degenerate which we can then propagate away. I have a possible solution
for this that I'm playing with.
I suspect the right path is to continue down this path.
Jeff
