On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther <rguent...@suse.de> wrote: >> > Any reason why you didn't just re-use the tree-ssa-live machinery? >> >> Probably I didn't know about it or didn't want to keep the full life >> problem life (it tries to free things as soon as possible).
I think it'd be good to use the tree-ssa-live stuff instead of a local liveness dataflow solver, even if that may allocate a bit of extra memory. tree-ssa-live is very smart about how liveness is computed. I'll experiment with using it in tree-vrp. >> > And any reason why you don't let a DEF kill a live SSA name? AFAICT >> > you're exposing all SSA names up without ever killing a USE :-) >> >> Eh ;) We also should traverse blocks backward I suppose. Also >> the RPO traversal suffers from the same issue I noticed in PRE >> and for what I invented my_rev_post_order_compute ... >> (pre_and_rev_post_order_compute doesn't compute an optimal >> reverse post order). Eh, what do you mean with "optimal" here? Yikes, I didn't know about my_rev_post_order_compute. How horrible! That function doesn't compute reverse post-order of the CFG, but a post-order of the reverse CFG! > The following not. Queued for testing (though I doubt it will > help memory usage due to the use of sbitmaps). I think > jump threading special-casing asserts and the equiv bitmaps are > the real problem of VRP. What testcase did you notice the live > issue on? I don't remember exactly what test case it was, but it had a large switch in it. Maybe Brad Lucier's scheme interpreter, but I 'm not sure. Ciao! Steven
