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
