This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Timing information for CFG manipulations


> Bootstrapped and regtested on i686-pc-linux-gnu, flow2 is now
> 
>  flow 2                :  33.92 (16%) usr   0.10 ( 2%) sys  34.00 (16%) wall
> 
> So, two home runs in one day!  (Two goals in one day? ...)
Good news.  I've planed those two changes for a while, so don't expect another
two hours tomorrow :)
Just curious, how does the time compare to the older gcc versions?

> Each sample counts as 0.01 seconds.
>   %   cumulative   self              self     total
>  time   seconds   seconds    calls  ms/call  ms/call  name
>  16.66     29.10    29.10 72698858     0.00     0.00  bitmap_operation
>  12.43     50.81    21.71       13  1670.00  4145.64  calculate_global_regs_live

For some purpose, the liveness analyzis by df module appears to work faster than
flow.c in non-patological cases (such as combine.c, where flow liveness takes
about 5-7%, but df.c in my webyzing pass did take about 1%).

I wonder if we can't speed up the flow.c pass considerably.
What other functions (except for bitmap_operation) does have more than 10
millions of calls? Do we run into problems with too much RTL traversal
or it is purely dominated by the dataflow bitmaps?

Honza
>   9.86     68.04    17.23  9305997     0.00     0.00  cached_make_edge
>   5.57     77.77     9.73    67331     0.14     0.38  try_crossjump_bb
>   4.03     84.81     7.04                             htab_traverse
>   2.99     90.03     5.22    27855     0.19     0.19  sbitmap_intersection_of_su
> ccs
> 
> Brad


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]