On Thu, Oct 4, 2012 at 11:43 AM, Steven Bosscher <stevenb....@gmail.com> wrote: > On Wed, Oct 3, 2012 at 5:35 PM, Steven Bosscher <stevenb....@gmail.com> wrote: >> The "worst" result is this: >> Compressing live ranges: from 726174 to 64496 - 8%, pre_count 40476128, >> post_count 12483414 >> >> But that's still a lot better than before the patch for the same function: >> Compressing live ranges: from 1742569 to 73069 - 4%, pre_count 40842330, >> post_count 12479992 > > Walking basic blocks with FOR_EACH_BB_REVERSE gives: > > Only FOR_EACH_BB_REVERSE: > Compressing live ranges: from 1742579 to 429746 - 24% pre_count > 41106212, post_count 34376494 > Compressing live ranges: from 1742569 to 63000 - 3% pre_count > 40835340, post_count 11055747 > > FOR_EACH_BB_REVERSE + need_curr_point_incr: > Compressing live ranges: from 726184 to 416529 - 57% pre_count > 40743516, post_count 34376846 > Compressing live ranges: from 726174 to 61840 - 8% pre_count 40472806, > post_count 11055747 > > The combination of the two changes takes ~20s off the ~180s for "LRA > create live ranges".
Isn't _REVERSE vs. non-_RESERVE still kind-of "random" order? Thus, doesn't the above show there exists an optimal order for processing which we could use? (I realize _REVERSE is a simple solution, but might there not exist a pathological case where _REVERSE is even worse than non-_REVERSE?) Richard. > Ciao! > Steven
