On Thu, Oct 4, 2012 at 6:56 PM, Steven Bosscher <stevenb....@gmail.com> 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