[RFA] [PATCH] [PR tree-optimization/68619] Avoid direct cfg cleanups in tree-ssa-dom.c [0/3]

[RFA] [PATCH] [PR tree-optimization/68619] Avoid direct cfg cleanups in tree-ssa-dom.c [0/3]

[Jeff Law]

Richi and I have been discussing revamping slightly how DOM handles 
conditionals which it detects are always true or always false.

During gcc6 stage1 I added code to allow DOM to clean them up 
immediately, primarily to avoid the waste of having the threader handle 
those cases.  It was also believed that by cleaning things up during the 
DOM walk we could realize some secondary benefits (certain PHIs become 
more likely to collapse down to a const/copy which can then be propagated).

That code causes an interesting problem as shown by 68619.  Essentially 
the CFG has 3 loops, one is a natural loop, the other two are irreducible.

DOM finds conditionals which it can optimize to true/false.  It removes 
the unreachable edges and everything seems perfect.  Except that removal 
of those edges causes the irreducible loops become reducible.  This is a 
good thing, except....

Now we have two new natural loops, which triggers a checking failure 
because we haven't set up loop structures for the newly exposed natural 
loops.

Richi's suggestion (before this problem was reported) was to have DOM 
leave the CFG alone, but otherwise optimize as-if the edges had been 
removed.  Final removal of the edges would be left to cfg_cleanup.  He 
also pointed me at SCCVN which does something similar.

This change essentially has DOM working in the same was as SCCVN.  The 
change is broken into 3 parts.

1. Refactor the code from tree-ssa-sccvn.c into domwalk.c  Essentially 
it's 4 new member functions that a dominator walker can optionally use 
to improve it's behaviour when the pass might make certain edges 
unexecutable.  I need someone to review these changes.  If you've got a 
better name for the member functions, certainly pass them along.  I'm 
not particularly happy with maybe_clear_unreachable_dom.  It feels like 
an internal implementation detail has leaked out, but I'm not really 
sure how to fix it, so any suggestions there are certainly welcome

2. Use the new member functions in tree-ssa-dom.c.  It's pretty simple 
stuff.

3. New tests.  One is the actual 68619 testcase.  Two ICEs for minor 
bugs found during development/testing, one case where we optimize better 
now than before, one for a missed optimization during development.

The patchset as a whole has been bootstrapped and regression tested on 
x86_64-linux-gnu.

Jeff