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


Gabriel Dos Reis wrote:-

> What worries is the alternative he's proposing.  My personnal view is
> to have ERROR_MARK_XXX for TYPE, DECL and such in order to enhance
> the tree type system and maintainability.

Changing tack a little now, but still on the topic of violent changes
to improve readability 8-)

I've often wondered whether we might do better type-wise to actually
use separate types, and refer to them as separate types, rather than
having every function take an effectively typeless "tree" as input.
This alone would help type safety quite a bit.  If we used separate
types, it would be a good idea, I suspect, to not use macros as
accessors as frequently as we do now, but instead to have each member
of the tree union have its own names for the common fields.  I realise
that the macros improve maintainability for moving stuff around, but I
think a lot of that problem is caused by extreme overloading of
e.g. the bitfields in tree_common whose name doesn't correspond to
what they are used for for most types.

An illustrative example of what is wrong with the current approach:
can you tell me exactly which bit fields in tree_common are used by,
say, an IDENTIFIER_NODE across front ends, and which are free, just by
looking at the documentation in tree.h?  [You have a better chance now
because I updated the documentation in tree.h a few months back from
my own investigations; I found it didn't mention at least three of the
bits.]  If identifiers had their own struct without attempting to
share everything with tree_common, this question would not even arise.

It would also help towards solving the space-issue for identifiers,
which currently take up far more memory than they really need, and
pushes them into the next GC allocation bucket.

Am I right in thinking that the only common thing that every "tree"
really needs to have is the chain element and tree code?

Neil.


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