Re: PCH, and more generally C++ parser performance

[Geoff Keating <geoffk at cygnus dot com>]

> From: Joe Buck <jbuck@racerx.synopsys.com>
> Date: Tue, 29 Aug 2000 19:33:25 -0700 (PDT)

> Geoff Keating writes:
> > Constructors, destructors, variable definitions, non-inline procedure
> > definitions all have to be handled specially, because they all produce
> > assembler output.  You can't lazily compile
> > 
> > int x = 3;
> > 
> > even in C because even if 'x' is never used in a particular
> > compilation unit, some other unit might use it.  The options I see for
> > such code are:
> > 
> > - don't allow these
> > - don't precompile these
> > - save a chunk of assembler input which gets stuck in when the PCH is
> >   used.  This would have the disadvantage that you could have
> >   conflicts if any assembler was output before the PCH was included,
> >   so you would have to prohibit this.
> > - be really clever, make sure the assembler has no conflicts
> >   by (say) renaming internal symbols.  This would be hard.

...
> So what to do instead?  Something like "save a hunk of assembler"?
> Do you intend for PCH's to be machine-independent or machine-dependent?

PCHs will be target-dependent because headers are target-dependent.  I
haven't thought about host-dependency yet, it will probably depend on
what is convenient.

> Perhaps a limited number of common forms, corresponding to constructors
> and initializers could be supported in a machine independent way.
> The two most obvious things to support are the equivalent of
> 
> int x = 3;
> 
> and
> static some_class some_obj;
> 
> where a note saying "set x to 3" or "include constructor and destructor
> for some_obj" could be represented in a machine-independent way.

This is something to consider after the initial implementation.  I'd
be happy to just get declarations working first.  Constructors would
be the next obvious step.
-- 
- Geoffrey Keating <geoffk@cygnus.com>