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

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Dec 1, 2015 at 10:32 PM, Jeff Law <law@redhat.com> wrote:
> 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...

Yeah, I have partially working patches lying around to "fix" CFG cleanup to
avoid this.  Of course in the case of new loops appearing that's not easily
possible.

> 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.

Yeah, the issue here is that DOM isn't tracking which edges are executable
to handle merge PHIs (or to aovid doing work in unreachable regions).  It should
be possible to make it do that much like I extended SCCVN to do this
(when doing the DOM walk see if any incoming edge is marked executable
and if not, mark all outgoing edges as not executable, if the block is
executable
at the time we process the last stmt determine if we can compute the edge
that ends up always executed and mark all others as not executable)

Richard.

> Jeff
>
>