[PATCH][PR tree-optimization/67816] Fix jump threading when DOM removes conditionals in jump threading path

[Jeff Law]

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