Merge cpplib and front end hashtables, part 1

[Neil Booth]

Neil Booth wrote:-

> This is a first step, of three or four, towards merging cpplib's
> hashtables with those of the C-family front ends, which will result in
> blowing away most if not all of cpphash.c.

Well, I've got an merged hashtable implementation on my hard drive.
It gets some way into stage 2 of a bootstrap but dies on c-decl.c.
c-delc.c uses a lot of identifiers, causing a hashtable expansion,
upon which cpplib gets very confused.

This is because CPP stores pointers to hashnodes in its hashtable,
whereas stringpool.c stores the actual hashnodes.

The advantages of CPP's method is that table expansion is faster,
because it only involves shifting a bunch of pointers to the new
table, rather than whole objects.  Also, CPP is able to assume that
hashnodes never change their memory location, an important assumption
that it makes everywhere.

The advantage of the current stringpool.c method is that it saves an
indirection, doesn't waste a pointer per hashtable entry, and saves a
hashnode allocation for each insertion.

So, is it worth losing the advantages of the current method for a
merged hashtable implementation?  Only the C front ends need pay the
price; the other front ends can have the less expensive stringpool.c
implementation that now exists.

I think it's still worth it: by merging hash table implementations
we'll save a lot more than one pointer per item in storage space, and
the small inefficiency of indirection when dealing a hashnode would be
swamped by saving a lookup / insertion operation for each identifier
returned from cpplib.

Thoughts?

Meanwhile, I'll adapt stringpool.c to do it the cpplib way, for the C
front ends only, which is easy when its abstracted, and if all goes
well I'll post an initial patch soon.

Neil.