[RFA] Integrated hashtables for compiler + cpplib

Zack Weinberg zackw@Stanford.EDU
Fri May 18 23:43:00 GMT 2001


On Fri, May 18, 2001 at 10:20:33PM +0100, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > Am I confused, or are you calling init_stringpool twice for C front
> > ends? (once from cppinit.c and once from toplev.c)  Same for
> > set_identifier_size (which is harmless, but confusing).
> 
> init_stringpool: yes, toplev.c calls it.  I also need to call it from
> cpplib in case we're stand alone.  init_stringpool notices when it's
> called more than once and ignores subsequent calls.  Not pretty, but
> not that bad either.

Fair enough.

> set_identifier_size: No.  It needs to be called earlier than before,
> since cpplib gets initialised earlier.  Otherwise nasty things (tm)
> happen.  That's why I moved it.

Oh, okay.  I misread this bit, then.

> Like I said, set_identifier_size has an life expectancy of about 3
> days, anyway.  Don't worry about that part.

Good to know.  (I think that's the only thing stopping
tree_code_length[] from being made const.)

> > I don't like the #ifdef STANDALONE_CPP.  I think that stringpool.c
> > should be split in two, instead.  Leave the standalone code in
> > cpphash.c and wrap it from stringpool.c; do the extra work needed for
> > integrated mode there.  
> >
> > It's okay if we then need to link cpphash.o into every front end, as
> > long as it doesn't drag in the rest of cpplib.
> 
> Hmmm.  OK, I'll have a go, but it's not clear to me if it'll all fit
> together.  You might lose your statistics, for example - I did my best
> to preserve them in the patch I posted.

No big deal, I can figure out how to put them back later.

> > This would also make it very easy to avoid breaking cpplib's ability
> > to have multiple reader objects active at the same time.  cpphash.o
> > refers to a reader object, and stringpool.o provides a dummy one to
> > front ends that don't need the whole megillah.
> 
> ? What's a megillah? :-)

"The whole megillah" is a Yiddish-ism for "the whole thing."
"megillah" all by itself apparently means "a long story."  Go fig.

> > stringpool.o is replaced by c-stringpool.o for C, which does the
> > complete integration dance.
> 
> Hmm.  So we have cpphash.o, stringpool.o and c-stringpool.o?  I'm not
> clear what you're thinking of here, but I'll see what I can do.

That's the basic idea.  I think you don't even have to take
stringpool.o out of libbackend.a for this to work.

> > > +make_identifier (node)
> > 
> > Needs a comment and possibly a more descriptive name.  This turns a
> > phase 4 (preprocessing) identifier into a phase 7 (compilation)
> > identifier, I *think*.  If so,
> > 
> > /* NODE is an identifier known to the preprocessor.  Make it known
> >    to the C front end as well.  */
> > 
> > or something like that.
> > 
> > This routine is a good example of why the STANDALONE_CPP trick is bad;
> > I don't believe it will ever be called in the S_C case, but you're
> > leaving it in the object module anyway.
> 
> Well, it exists for whatever reason the distinction between
> get_identifier and maybe_get_identifier exists.  I'm not entirely
> clear on that, but I belive it's something to do with the compiler
> avoiding outputting (debug? object?) information for stuff that isn't
> used.  That distinction is the ERROR_MARK / IDENTIFIER_NODE
> distinction we have now, and make_identifier converts from ERROR_MARK
> to an IDENTIFIER_NODE.

Now I'm lost again.  I thought make_identifier was because cpplib
would create tree nodes which weren't fully visible to the C front
end, and those would have ERROR_MARK for their type.

maybe_get_identifier is different again, it doesn't insert at all, and
it's used 'way in the back end to avoid creating random IDENTIFIER_NODEs
when we go to generate external references.  I'm not sure it's actually
necessary (anymore).

-- 
zw               "Shouldn't a witch be eccentric?"
                 "I hope not. I've never been good at cackling."
                 	-- Reinder Dijkhuis, _Rogues of Clwyd-Rhan_



More information about the Gcc-patches mailing list