C compile time

[Jan Hubicka]

> Dara Hazeghi wrote:
> 
> >Okay, here's the updated table. Checking is disabled
> >on all compilers.
> >
> >gcc version     -O0     -O1     -O2     -O3
> >2.7.2.3         128.04  131.02  163.51  176.01
> >2.8.1           128.86  140.79  182.35  194.63
> >2.90.29         130.60  140.57  186.29  199.32
> >2.91.66         132.44  148.48  203.71  219.21
> >2.95.3          143.38  180.97  250.94  276.85
> >3.0.4           169.79  210.73  320.24  365.15
> >3.2.3           193.48  269.43  424.74  519.85
> >3.3             184.15  282.57  442.64  529.93
> >3.3-branch      184.15  283.89  443.66  535.10
> >3.4-mainline    195.34  302.02  483.84  704.59
> >3.4-mainline*   175.84  269.78  426.77  627.13
> >3.5-tree-ssa    223.33  327.91  503.58  702.11 
> >
> 
> So with Andrew P's patch, mainline C is faster than 3.3, hurray!
> 
> The slowdown at -O3 is of course due to unit-at-a-time, which can be a 
> big memory sucker if there are lots of opportunities to inline static 

I was doing some estimates there, and for compiling SPEC sources the
slowdown is proportinal to the code size growth caused by
unit-at-a-time.  So the problem does not seem to be increased memory
overhead, just the fact that we find more inlining opurtunities and
inline more. GCC is probably good testcase for this as many parts are
ordered top-down instead of bottom-up or old inliner likes.

It only indicate that we should re-think the unit-at-a-time inlining
heuristics.  I will try to come with something.

> functions (there is a PR for that IIRC).  What would that number look 
> like with -fno-unit-at-a-time?
> 
> Do you also have numbers for binary sizes and runtime performance?  :-)
> 
> >*this includes Andrew Pinki's patch for PR10962
> >
> That patch looks like a very nice improvement.
Ineed :)

Honza
> 
> Gr.
> Steven
>