This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: Unit at time compilation mode II


> On Tuesday, February 11, 2003, at 02:17 AM, Zack Weinberg wrote:
> >(That would entail that unit-at-a-time compilation was mandatory,
> >which I think should be just fine particularly if we can knock down
> >the size of DECL nodes a bit.)
> 
> I hope this doesn't have a negative compilation speed impact on a small 
> (128M) machine on real code, either by itself, or in conjunction with 
> pch.

I've sent some analysis of it earlier to the list.  In the current form
it brings about 1% speedup on i386 with -O2 (so no inlining, just
calling convetion changes).  This seems to be enought to elliminate the
slodown the patch causes (not by itself, but by exposing more memory to
GCC).  On the other architectures not benefiting from the local function
optimization yet the speedup is about 0.5-0.7% (measured on x86-64)
there will likely be 0.3-1% slowdown.  (I measured 0.6% on x86-64)

It may be seen as a lot of course.  At the present I am not enabling
unit-at-time at -O2, so this don't happen and I hope in future we will
get more optimizations in place so it will pay back for other
achitectures too.  The i386 example just shows that it is not really
that dificult.

Concerning the memory footprinit, I made just quite primitive
measurements, but for largest files in GCC directory (combine.c insn-*)
I didn't measured more than 20% increase.  This is because tree
representation is more compact so most of memory is eaten by RTL, but of
course it may get higher for files with dazilions of very small
functions, where RTL overhead is minimal and tree overhead maximalized.

The plan to switch into callgraph code in all compilation modes does not
impose any extra overhead (well, adding callgraph edge for each call,
but that is really minimal), just cleans up the compiler.

Concenring the communication with PCH, I hope I am safe.  I would like
to get callgraph code saved to the disc for intraprocedural
optimization, but in current state it does not happen.  Since PCH does
not let you to expand any function body, the callgraph code will not be
executed so everything should just work.  I tested it on trivial
testcases.

Honza


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