This is the mail archive of the
mailing list for the GCC project.
Precompiled headers, etc, on tree-serialize branch
- To: gcc at gcc dot gnu dot org
- Subject: Precompiled headers, etc, on tree-serialize branch
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Sun, 7 Oct 2001 15:02:46 -0400
As part of tree-serialize branch work i've been doing the past few weeks
(which is doing serialization mainly for the purposes of interprocedural
optimizations and whatnot) and because the redhat pchmerge-branch is
currently having fun with garbage collector related problems, i took the
currently working tree/rtl serialization, and threw together the pieces
necessary to do basic C precompiled headers.
In fact, the main thing it doesn't do right now is verify the
precompiled header is still valid.
The way serialization is done by redhat, and the way i do it, are
somewhat different in implementation, but basic approaches are pretty
much the same.
In fact, once the pchmerge branch has all the bugs worked out of code,
i'll probably take it and use it (or Apple's code, if that is better),
after converting it to use a database, rather than flat file.
But, if someone really wants to see how much faster it is to do
precompiled headers for C, it works well enough on the tree-serialize
branch to give this a test for basic performance tests. Certainly not
for real projects yet, since it's not validating the precompiled headers
are still valid, and because it serializes everything you compile.
Which brings me to the second thing you can see the advantages of:
Attempting to do recompilation of only modified functions. The real
tricky part here, AFAIK, is making labels that are output not conflict.
However, to give you some idea how much faster this would make gcc,
here's the current minimum bound on a gcc compilation, as witnessed by
just precompiling a file, and generating the assembly from the
precompiled file only:
(produces an expr.i.pch, since, as i said, it serializes anything you
ask it to compile)
cp expr.s before.s
diff expr.s before.s
The redhat stuff can't do lazy loading, etc, which is a goal of the
tree-serialize stuff (i use any DBM compatible database available,
rather than use our own flat file format).
Remember, all of this is just to give you some idea of what the speed
gains will be like/what is possible.
Please don't tell me about bugs, i know most of them.
It's not my main goal to produce precompiled headers, or even recompile
only changed functions, i just thought people might want to see what the
performance gains are going to be like.
PS: C++ is currently broken on this branch, since i haven't finished the