[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