Re: [PATCH] Update SSA_NAME manager to use two lists

[Jeff Law <law at redhat dot com>]

On 10/01/2015 04:00 AM, Richard Biener wrote:

> Apart from what Jakub said - this keeps the list non-recycled for example
> after DCE if that doesnt call cleanup_cfg.  Likewise after passes that call
> cleanup_cfg manually.  It also doesn't get called after IPA transform
> passes (which would require calling on each function).
>
> To at least catch those passes returning 0 (do nothing) I'd place the
> call into execute_todo instead, unconditionally on flags.
I can speculate there's pathological cases where it'd be useful, but 
that in the general case it'll be small.  It's easy enough to do some 
testing around this.

I'm also still pondering whether or not to have the code simply adapt 
itself to the conditions.   Essentially allowing immediate recycling up 
until the point where we release an SSA_NAME after removing an edge. 
At that point it'd switch to deferred mode until the next time the 
pending list is flushed.

We'd have to arrange to get notified of edge removals, obviously.  I'm 
also still pondering the long term safety issues of that scheme as well 
as the implementation & testing details.


> > @@ -607,6 +626,7 @@ unsigned int
> >   pass_release_ssa_names::execute (function *fun)
> >   {
> >     unsigned i, j;
> > +  flush_ssaname_freelist ();
>
> which would make this redundant as well.  I suppose it would be
> interesting to see some before/after
> statistics of the release_ssa_names pass.  I expect the number of
> holes removed to increase, hopefully
> not too much (esp. important for analysis passes using sbitmaps of SSA names).
There's some TLC that needs to happen in pass_release_ssa_names -- it 
knows far too much about the underlying details of name management.  All 
that code really belongs in the name manager itself and the pass should 
just issue the call into the name manager to release & pack the data. 
That's one of the refactorings I mentioned in my reply to Jakub.

Essentially this should be driven by the name manager and occur at 
points where it's safe and likely profitable.  Safe points occur between 
passes.  Profitability can likely be estimated cheaply within the 
manager itself since it has a good handle on what's in the free lists vs 
the overall size of the name table.

The other area ripe for refactoring and extension are the verification 
bits.  I was torn whether or not to tackle that first or as a follow-up. 
 I ultimately chose the latter.

Jeff