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]

Re: Shrinking INTEGER_CSTs and IDENTIFIER_NODEs


On Sun, Aug 27, 2000 at 09:31:41PM -0700, Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zack@wolery.cumb.org> writes:
> 
>     Zack> Ideas?
> 
> You really are going down all the funny paths I've explored.  That's
> good -- perhaps you'll follow through somewhere where I did not.

I'm reaching a point of diminishing returns, though, given the
extremely limited amount of time I have left before I vanish.
get_identifier using a crap algorithm is one thing, easy to spot and
not so hard to fix.  Finding all the places that expect INTEGER_CSTs
to be mutable is borderline.  I did look at it for a bit and couldn't
see any good way to make the compiler or the checking macros catch
violations, and I don't want to do it without.  And most of the
changes you're talking about below would require me to comprehend the
C++ front end in all its detail, which is just not happening.

On a lot of this stuff, I'm hoping someone else will pick up the
ball. :)

> ... for every global, we have an IDENTIFIER_NODE for the mangled
> name; but mangled names don't use any of the extra fields.  So the
> extra fields are just wasted space.  (In fact, all we really need
> for the mangled name is a string; all of tree_common is wasted.)

I noticed that while working on get_identifier, yes.

> One alternate design is to just store the strings directly in
> DECL_NAME/DECL_ASSEMBLER_NAME and use IDENTIFIER_NODEs only in the
> symbol table.  As you exit a scope, throw away the symbol table,
> keeping only the strings.  Right now, IDENTIFIER_NODE is used both to
> implement the symbol table (via the TREE_TYPE, namespace_bindings,
> TREE_CHAIN, etc.) and as the thing to which DECL_NAME and
> DECL_ASSEMBLER_NAME point.

Sounds promising.  I'm not sure I know what you mean by "throw away
the symbol table", though.  I will try to look at this as soon as
someone reviews the big patch I already sent out for this area of the
code (http://gcc.gnu.org/ml/gcc-patches/2000-08/msg01097.html).  If I
try to do 'em at the same time I'll just mangle my work area.

zw

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