Re: [PATCH] Fix PR54489 - FRE needing AVAIL_OUT

[Richard Guenther <rguenther at suse dot de>]

On Fri, 14 Sep 2012, Steven Bosscher wrote:

> On Fri, Sep 14, 2012 at 11:43 AM, Richard Guenther <rguenther@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.

Ok.  Note that VRP likes to know liveness at a given stmt (but
actually doesn't use it - it would, with my patch) here:

              /* If OP is used only once, namely in this STMT, don't
                 bother creating an ASSERT_EXPR for it.  Such an
                 ASSERT_EXPR would do nothing but increase compile time.  
*/
              if (!has_single_use (op))

that really wants to know if anything would consume the assert, thus
if OP is live below stmt.

> >> > 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!

Ok, well - then that's what we need for compute_antic to have
minmal number of iterations and it is what VRP needs.  Visit
all successors before BB if possible.

;)

> 
> > 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.

I see.

Richard.