Code Bloat g++

Per Bothner
Sun Feb 20 15:26:00 GMT 2000

Zack Weinberg <> writes:

> Well, I'd like to facilitate smaller debug info, but I'm not sure how
> precompilation helps.

Well, there is an indirect way it can help:  I was talking about
generating a repository of pre-compiled .o files.  Martin complained
about the Makefile- and other hassles of managing repositories.
Well, if we do both at the same time, the problems go away.

Specifically, assume pre-compiling foo.h produces foo.hx.
The same driver program that generates foo.hx also generates foo.o
(in the same target directory).  foo.o is generated *as if* by
a foo.c containing:
        #pragma implementation
        #include "foo.h"
except we foo.h as containing an implicit #pragma interface.
We also put an annotation in foo.hx that we have generated a foo.o.

When compiling bar.c, which contains an #include foo.h, the
compiler looks for the pre-compiled foo.hx.  It loads foo.hx.
Because it knows there is pre-compiled foo.o, it can compile
bar.c *as if* foo.h had a #pragma interface declaration.  Thus
it can leave out of bar.s all debug info, vtables, and out-of-line
in lines for foo.h, just like we *already do* for the old
pragma interface/implementation code.

We do need to make sure that when linking foo.o gets pulled in.
The best way to do that is to make sure that foo.o is part of
the archive for the library it implements.  E.g. for a libstdc++
header file, we make sure foo.o is included in

Thus there is no need to change user Makefiles.  Whoever is
generating pre-compiled header files has to do a little extra work,
but little or nothing extra beyond doing whatever is alread
involved in creating/installing the pre-compiled header files.

How much it buys us is unclear.  On old non-template header files
#pragma interface/implementation made quite a difference, so
my idea would do the same.  When templates are involved, it is
more difficult. For explicit instantiated templates, we should
get the savings.  For implicitly instantiated templates, it
would depend on how template instantiation is managed (and how
clever we are); since I don't know much about how template
instantiation, I can't say more.

> The precompilation scheme I'm looking at right now basically
> constructs parse trees for all the information in the headers and then
> dumps that out.  Think of it as stopping right before
> rest_of_(decl_)compilation, although that's not quite accurate since
> the tree->RTL transform happens before that.  Debug info, as I
> understand it, needs to be written after the optimizer finishes,
> because it depends intimately on the form of the final assembly
> output.

We're talking about two different kinds of debug info:  Debug info
for types and declarations, and debug info for function bodies.
My scheme helps with the former, not the latter, so the "final
assembly output" is not an issue.

Again, if the problem of debug info is overwhelmingly that of
function bodies, then my idea won't help much.

> I'm nervous about breaking semantics, though.  I want precompiled
> headers to be exclusively an optimization, with no effect on the
> generated code.

It may be worthwhile considering two the kinds of header files
* Idempotent header files are purely a fixed sequence of
definitions/declarations, indepdendently of previous definitions or
inclusions.  Specifically, there is no conditional compilation,
except to guards against multiple inclusion and definition.
Also, header files can be included in any order.
* Non-idempotent header files.

I think most of the C++ header files that make pre-compiled
header worthwhile are idempotent ones.  These are straight-forward
to handle for both your pre-compilation scheme and for my idea,
because we don't have to be concerned about conditionals.
Non-idempotent header files are more difficult to deal with,
but they are perhaps less important.  They are also bad style
and dangerous, so concentrating on optimizing idempotent headers
has the ok side effect of encouraging cleam header files.
	--Per Bothner

More information about the Gcc mailing list