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
