On Thu, Oct 4, 2012 at 6:56 PM, Steven Bosscher <[email protected]> wrote:
> "Crude, but efficient" (tm) :-)
BTW with a similar approach I also time other bits of process_bb_lives:
timevar_push (TV_HOIST);
/* See if we'll need an increment at the end of this basic block.
An increment is needed if the PSEUDOS_LIVE set is not empty,
to make sure the finish points are set up correctly. */
need_curr_point_incr = (sparseset_cardinality (pseudos_live) > 0);
EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, i)
mark_pseudo_dead (i, curr_point);
timevar_pop (TV_HOIST);
timevar_push (TV_PRE);
EXECUTE_IF_SET_IN_SPARSESET (pseudos_live_through_calls, i)
if (bitmap_bit_p (DF_LR_IN (bb), i))
check_pseudos_live_through_calls (i);
timevar_pop (TV_PRE);
PRE : 12.20 ( 1%) usr
code hoisting : 34.03 ( 3%) usr
IOW that's ~46s out of ~180s *not* spent in walking the insns in
process_bb_lives!
I think this is due to the opening/closing of chains for all pseudos
live through the basic block at the start and end of process_bb_lives.
For this test case the cardinality of pseudos_live is as high as
max_reg_num/2 at its peak.
I tried to keep pseudos_live open for bb->prev_bb if there is a
find_edge(bb->prev_bb,bb), but that's when I ran into a problem with
inconsistent liveness data (that's what this message was about:
http://gcc.gnu.org/ml/gcc/2012-10/msg00035.html).
Ciao!
Steven
