On 08/01/2018 08:33 AM, Richard Biener wrote: > > Repeating the boiler-plate from 0/4 here again, in case you didn't read > it. This is the main patch (and thus big). It scraps all of the > SCCVN engine replacing it with RPO stuff but the stmt-based workers mostly > stay the same. > > > This rewrites the value-numbering algorithm used for FRE and PRE from > SSA SCC based to RPO based, thus switching from an algorithm that > handles SSA SCCs optimistically to one that handles CFG SCCs optimistically. > > The main motivation for this besides being more optimistic was that > adding CFG context sensitive info is easier in RPO style. Also > tracking availability and thus making expression simplification not > based on values like with SCCVN is possible which allows us to remove > all the warts that scrap side-info we store on SSA names. It also > fixes PR86554 which is another manifestation of the same issue. > > Another motivation was that we're in the need of applying value-numbering > on regions like when unrolling loops or as part of cleanup on code > generated by other passes like the vectorizer. Thus this rewrite > makes sure that the value-numbering works efficiently on regions > (though in a non-iterative mode), avoiding work and space that is > on the order of the function size rather than the region size to work on. > Sofar the GIMPLE unroller makes use of this, scrapping its own > simple constant propagation engine. I expect that DOM could get rid of > its value-numbering and instead use a non-iterative RPO-VN run as well. Yea, I think we kicked this (using a single RPO-VN and dropping DOM's own hashing).
I've got a ton of cleanups to do over the next couple months (primarily related to the VRP/DOM interactions and making DOM usable on subgraphs). I'll try to slot the RPO-VN changes in after those. jeff