This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ICE in change_address at emit_rtl.c


On Sun, Nov 25, 2001 at 11:51:13AM +0000, Neil Booth wrote:
> 
> Certainly, I'm not advocating taking them out of the tree union.  I
> suppose what I am advocating, but in different words, is the death of
> tree_common.  We then have
> 
> struct tree_identifier
> {
>   tree chain;
>   ENUM_BITFIELD(tree_code) code:8;
>   [...]
> };
> 
> with the same two common fields for other trees, but everything else
> is specific to the struct tree_xxx in question.

Ah, I understand.  I'm in favor of the same thing, although I think
the list of required fields is different.

> > Less! An identifier has no use for the chain, or for most of the flags.
> 
> Are you certain of that?  Nothing anywhere chains identifiers together
> into lists?

Nothing anywhere chains identifiers together into lists.  I know,
because I killed the code that used to use TREE_CHAIN of
IDENTIFIER_NODEs.  It was the bucket chain pointer for the old
non-expandable symbol hash table.

Identifiers really *aren't* trees.  They're bags of language-specific
data hanging off of tokens.  Notice how, throughout the compiler, a
slot in a data structure that carries an IDENTIFIER_NODE never carries
any other kind of tree.  Notice how the only fields of tree_common
that are used by IDENTIFIER_NODEs are flag bits - for decidedly
C-specific purposes, and for information that belongs to a DECL, not
the identifier.

So my plan is to make identifiers not be trees anymore, at all; hash
table entries point to (or contain) just the struct lang_identifier.
Language independent code that sets flag bits in IDENTIFIER_NODEs is
either nuked, or changed to use lookaside tables.  Language dependent
code that does that can put its flags in lang_identifier, or else in
the appropriate DECL node.

This doesn't really affect anything that you do - you're looking more
at expression and constant nodes, it sounds like.

> > There are some counter-pressures against shrinking trees too far.  One is
> > the real danger of running out of tree_code values.  That's an 8-bit field
> > and C++ has more than 200 tree codes.  Another is the demand for flag bits.
> > And there are very few trees that don't need at least a cons-cell worth of
> > pointers; that's eight bytes (on a 32-bit machine) right there.
> 
> What I had in mind wouldn't add any tree_code values, at least I don't
> think so and not initially.
> 
> I'd also like to see us go down the road that rth mentioned,
> i.e. losing all trees with side effects - something else that causes
> no end of special cases to be scattered all over the place.  That
> would get rid of {UN,}SAVE_EXPR and {PRE,POST}{DECREMENT,INCREMENT}
> etc., and some bugs that cause existing outstanding PRs I think.  If
> we are in danger of having more than 256 tree codes, I think that's a
> sign that something is wrong.

Eliminating SAVE_EXPR and friends would be a good idea (kenner's
opinion notwithstanding) but doesn't truly address the problem.  There
are other reasons why we might need more tree codes.  For instance,
languages with lots of intrinsic functions (Fortran 90 comes to mind)
may want to assign each their own tree code so that tree optimizers
can deal with them directly.

There's already a collision between some tree code and the byte value
written by GC object poisoning, which can make debugging harder than
it has to be.

Also, think about padding.  struct { char; tree; } is no smaller than
struct { short; tree; } on any modern host.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]