Re: string pools, final version (committed)

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Fri, Nov 17, 2000 at 07:06:28PM +0000, Neil Booth wrote:
> Zack Weinberg wrote:-
> > Approved by Mark Mitchell.  Bootstrapped with latest CVS on
> > i686-pc-linux-gnu.  The changes from the previous version are:
> > 
> > - improve commentary
> > - update changes in varasm.c to match recent changes to the constant
> >   pool
> 
> Zack,
> 
> I don't fully understand your patch, but this usage of pools looks
> similar to what I do with the ident_pool in cpplib.
> 
> It would be nice to find a way we can merge these pools for integrated
> cpp, but in such a way that cpplib can still function independently
> when it has to, for cppmain.  I know you want to merge the hashtables
> eventually, do you have any nice ideas in mind?

stringpool.c is almost entirely independent of the compiler proper as
it stands.  It does have a bunch of tree-specific code, but that could
theoretically be moved back to tree.c.  However, we run into a
fundamental difficulty, and I'm open to suggestions how to resolve it.

As it stands, each hash table entry contains the length of its string,
a pointer to the text of its string, and a pointer to affiliated data.
Currently, "affiliated data" is always a tree, specifically an
identifier_node.  For cpplib to use that "affiliated data" pointer,
it'd need a way to tell stringpool.c that the affiliated data is a
cpp_hashnode structure, not a tree.  That's not so hard.  The trouble
comes when you're using the integrated preprocessor.  Now both cpplib
and the compiler proper want to use the affiliated data pointer.  Now
what do you do?  Giving both of them their own static slots is not an
option; now you've doubled the cost for all hash table entries, and
for all front ends whether or not they need it.

In short, we need a mechanism for N different chunks of affiliated
data to be associated to a string constant, with dynamic allocation of
the slots and without massive time or space overhead.  Note that if we
could do this, we could use it in several other places as well.  For
instance, varasm.c's constant pool could hang its data off the string
pool instead of using a separate hash table.

zw