Re: [patch][lra] Improve initial program point density in lra-lives.c

[Vladimir Makarov <vmakarov at redhat dot com>]

On 10/04/2012 12:56 PM, Steven Bosscher wrote:
> On Thu, Oct 4, 2012 at 6:12 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> > > > 0.6% sounds really very different from my timings. How much time does
> > > > create_start_finish_chains take for you?
> > > 0.65% (2.78s).
> > >
> > > Actually, I have a profile but I am not sure now that it is for PR54146.
> > > It might be for PR26854.
> > >
> > > I'll check it again to be sure.
> > Not it looks about the same.
> Well, that's very strange. Maybe we measure these things differently?
> I just hi-hack a timevar, so I measure e.g. the time spent in
> create_start_finish_chains like so:
>
> Index: lra-lives.c
> ===================================================================
> --- lra-lives.c (revision 192052)
> +++ lra-lives.c (working copy)
> @@ -770,6 +812,7 @@ create_start_finish_chains (void)
>     int i, max_regno;
>     lra_live_range_t r;
>
> +timevar_push (TV_CPROP);
>     lra_start_point_ranges = XCNEWVEC (lra_live_range_t, lra_live_max_point);
>     lra_finish_point_ranges = XCNEWVEC (lra_live_range_t, lra_live_max_point);
>     max_regno = max_reg_num ();
> @@ -783,6 +826,7 @@ create_start_finish_chains (void)
>            lra_finish_point_ranges[r->finish] = r;
>          }
>       }
> +timevar_pop (TV_CPROP);
>   }
>
>   /* Rebuild LRA_START_POINT_RANGES and LRA_FINISH_POINT_RANGES after
>
>
> so that I get the timings in the -ftime-report like so:
>
>   CPROP                   :  43.14 ( 4%) usr
>   integrated RA           : 200.81 (17%) usr
>   LRA non-specific        :  62.18 ( 5%) usr
>   LRA virtuals elimination:  61.71 ( 5%) usr
>   LRA reload inheritance  :   6.41 ( 1%) usr
>   LRA create live ranges  :  139.75 (13%) usr
>   LRA hard reg assignment : 130.90 (11%) usr
>   LRA coalesce pseudo regs:   2.45 ( 0%) usr
>   reload                  :   9.09 ( 1%) usr
>
> "Crude, but efficient" (tm) :-)
>
> How do you measure the time spent in that function, and in
> remove_some_program_points_and_update_live_ranges?
You use AMD and I use Intel.  So it may be different with cache point of 
view.

Another thing is that I used gprof (-pg was used for bitmap.o lra*.o and 
ira*.o).  Your measurements are more accurate, I think, because it is 
without instrumentation and bitmap.o takes too much time. Bitmap does 
not work well in this case because they are too big and sparse.