On 10/04/2012 12:56 PM, Steven Bosscher wrote:
On Thu, Oct 4, 2012 at 6:12 PM, Vladimir Makarov <vmaka...@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.
