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

[Geoff Keating <geoffk at cygnus dot com>]

> Cc: Zack Weinberg <zack@wolery.cumb.org>, Stan Shebs <shebs@apple.com>,
>         gcc@gcc.gnu.org
> From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
> Organization: CMLA, ENS Cachan -- CNRS UMR 8536 (France)
> Date: 31 Aug 2000 06:53:22 +0200
> 
> Geoff Keating <geoffk@cygnus.com> writes:
> 
> | Zack Weinberg <zack@wolery.cumb.org> writes:
> | 
> | > Look over at the conversation I've been having with Mark Mitchell.  He
> | > thinks we can't get away with lazy parsing of anything in C++, and has
> | > some solid arguments for it.
> 
> Yes, I'm also of the opinion that you can't simply do lazy parsing in
> C++, unless you have indeed a very very sophisticated scheme to get
> name resolution right, especially to get the two-phase name lookup in
> templates (see 14.6 of the C++ Standard).  You also need to keep
> track of points of instantiation. 

...
> 	// nifty_counter.H
> 	class nifty_counter {
> 	public:
> 		nifty_counter();
> 		~nifty_counter();
> 
> 	private:
> 		static int count;
> 	};
> 	
> 	static nifty_counter counter;

This has been mentioned previously.  The construct

static nifty_counter counter;

cannot be easily precompiled, as it is a definition.  It would be
nearly as hard even if it was just

static int counter;

because the compiler must allocate memory for it.

So you simply have to save this definition away---this cannot be done
as text or as a token stream, because its meaning might change---and
output it each time the PCH is used.

In the worst case, consider someone who thinks it a good idea to feed
an entire .cc file to the precompiler, and whose `source' consists of

#include <foo.cc>
/* ha ha ha */

I don't think we have to make this work for PCH to be useful.

> That idiom is, for example, used to initialize the global stream
> objects in the C++ Standard Library.
> 
> The idea is generalized into the idiom "resource acquisition is
> initialization".  And we need to support it correctly, whether we like
> it or not.

I agree that it must be supported correctly if it supported at all.
I do not agree that PCH would be useless if it was not supported
fully, or even if it was not supported at all.  For instance, we could
make it work only for the special case of the global streams.

> | So, for instance, if we have something like
> | 
> | #include <everything.h>
> | int foo (int bar)
> | {
> |   bar = f(g(i<3>));
> | }
> | 
> | then during parsing, everything relating to "foo", "bar", "f", "g",
> | "i" gets loaded from a pre-compiled header file, as are their types
> | and so on.
> 
> Given that name lookup is not that simple in C++, I would like you be
> more precise here: how do you handle names found by unqualified name
> lookup? 

Name lookup is the determination of which, out of a set of possible
meanings for a name, is the one meant.  My scheme handles this by
loading in all the possible definitions of a name before name lookup
starts.  For instance, when loading "foo" I would load T::foo,
J::T::foo, and plain ::foo, if they were all defined.  (I might make
an exception for C::foo if C is not yet loaded; I think, but am not
sure, that under those circumstances "foo" cannot mean C::foo.)

The implementation I'm thinking of would hook into get_identifier.
It'd keep a second table of 'identifiers that are defined but not
loaded yet', and if an identifier was not found in the normal hash
table the second table would be checked, and if found there it would
be loaded in.  This approach is simple and reliable, and easily
made smarter.

-- 
- Geoffrey Keating <geoffk@cygnus.com>