[RFA] Integrated hashtables take 2
Neil Booth
neil@daikokuya.demon.co.uk
Sat May 19 12:26:00 GMT 2001
Mark,
I'm thinking of going with this. This is declared in cpplib.h.
struct cpp_hashnode
{
/* Takes up space of tree_common. */
struct
{
PTR chain;
PTR type;
char code_and_flags[4];
} ignore;
/* And tree_identifier. */
struct
{
unsigned int len;
const unsigned char *name;
} ident;
unsigned short arg_index; /* Macro argument index. */
unsigned char directive_index; /* Index into directive table. */
unsigned char rid_code; /* Rid code - for front ends. */
ENUM_BITFIELD(node_type) type : 8; /* CPP node type. */
unsigned char flags; /* CPP flags. */
union
{
cpp_macro *macro; /* If a macro. */
struct answer *answers; /* Answers to an assertion. */
enum cpp_ttype operator; /* Code for a named operator. */
enum builtin_type builtin; /* Code for a builtin macro. */
} value;
};
I'll put something similar in the C front ends as a struct
c_common_identifier, with ignore fields for things used by cpplib.
I'll put an enable-checking-only run-time check in the C front end
that offset_of (rid_code) matches between the two, similarly for len
and name, and that sizeof (cpp_hashnode) == sizeof
(c_common_identifier). That should be enough.
Agreed? Please let me know a.s.a.p. Note that packing everything
into one struct the way we do saves space over what we'd get from,
say, C++ inheritance, since we can save on alignment wastage.
We can try to save more space from the "tree_common" in a later patch,
but I don't want to do too much at once.
Besides, I have a plan to start to virtualize trees I'd like to put to
you.
Thanks,
Neil.
More information about the Gcc-patches
mailing list