Re: ICE in change_address at emit_rtl.c

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Zack Weinberg wrote:-

> I see definite benefits from using independent structures for all
> constants, identifiers, and possibly types.  I don't think it makes
> sense to go as far as separating all the current members of tree_union.
> It is genuinely useful to be able to treat the operands of any expression
> with the same logic, which argues for e.g. leaving declarations as part of
> the tree union (but then, it does the same for constants...)

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.

> 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?  Since everything else requires the chain (I think), I
imagine it'd be better to keep it so that identifiers remain trees
(assuming that the state of "being a tree" means to have the two
fields above, and GCC code can assume that).  Or do you have another
plan?

> 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.

Neil.