On Mon, Jan 23, 2017 at 5:07 PM, Jeff Law <l...@redhat.com> wrote: > On 01/23/2017 02:50 AM, Richard Biener wrote: >>>> >>>> >>>> So ideally DOM and EVRP would merge and CCP, copyprop and VRP >>>> would merge. It's probably not possible (or wise) to merge their >>>> lattices >>>> (maybe to some extent) >>> >>> >>> DOM's equivalency tables could be easily superceded by other >>> implementations. It's just two datastructures. A trivial const/copy >>> table >>> and a stack to allow unwinding the state of the const/copy table. >>> Throwing >>> away the basic const/copy table and replacing it with something built by >>> copyprop ought to be trivial. >>> >>> The big thing that would be left would be the scoped hash table for >>> tracking >>> redundant expressions. But I don't think that we'd necessarily have to >>> rip >>> that out to merge DOM with one of hte other passes. >>> >>> Hell we know DOM can fit well in any dominator based walk -- we used to >>> do >>> it as part of the into-ssa transformation. >> >> >> Sure. >> >> The question is whether we want to make warning "passes" more expensive >> by essentially doing a [E]VRP/DOM pass (but not doing any IL transform). >> >> I believe doing that is more reasonable than doing their own hacky >> analysis. >> >> Having less passes to choose to copy from for such static analysis (and >> the >> ability to tame compile-time by some switches) would be a good thing to >> have. > > Very true. But your comment seemed to be about merging DOM and EVRP or > other passes -- which is certainly possible and possibly even desirable. > > The more I look at our SCCVN implementation, the more I want to explore > trying to re-use that infrastructure to simplify DOM.
Certainly having a single way to hash/record stmts/expressions on GIMPLE would be nice. Not sure if the SCCVN one is perfect (enhancing the memory part further is on my TODO list). But I also want to merge SCCVN and DOM in the end. Well, rip out the 'SCC' part of SCCVN and replace it with a RPO style VN which makes it very similar to DOM. Ideally we'd have one "VN" we can configure (like enable a VRP lattice, disable memory handling to get a pure CCP, disable optimistic VN and thus require no iteration, etc.). It may make sense to keep (a similarly single!) SSA-propagator based VN (ccp/copyprop/VRP). Richard. > > Jeff
