Re: Saving extension semantic values from collection

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

(I noticed that my mailer has decided you wrote some things that I
actually wrote.  Please forgive the misattribution.)

    Richard>     Unfortunately, it's now a defacto part of the
    Richard> specification -- there are certainly other parts of the
    Richard> compiler that relied on this.

    Richard> Like?  I've looked at nearly all code that uses sizetype
    Richard> things by now and don't see any such.

It's possible you've eliminated some of them -- you've certainly been
all over this stuff lately, and you certainly know it best of all of
us at this point.  Let's not debate this point -- I'm not sure how
relevant it is.

    Richard>     Obviously, we could register and unregister the
    Richard> particular nodes that need it (including those that
    Richard> Martin is creating for the `__extension__' construct) --
    Richard> perhaps that is what you meant, rather than attempting a
    Richard> generic solution.

    Richard> I was thinking more general because I'm wondering if you
    Richard> really *can* prove that everything in the parse stack is
    Richard> pointed to by something else.

Speaking as an ex-mathematician, prove is a very strong word.  I can't
prove much about GCC, except for very local properties.  Perhaps
that's why I'm an ex-mathematician. :-)

But, we can run with --enable-checking, and test heavily.  We're
gradually doing more and more of this.  I've personally stared at the
G++ parser pretty hard, and I *think* it's OK.  We're also hoping to
rewrite that parser, not using bison, and so I'd rather not invest a
lot in additional bison infrastructure, if we can help it.  (BTW, I
would hope the new parser will handle C and Objective-C as well, so
that would take care of those languages.  Obviously, that won't help
Java, Ada, Fortran, etc.)

    Richard> I have a change pending that increases this by a lot,
    Richard> like up to 2048.

Still, we're talking about 2048 * 24 = 48K.  In GCC, that's like
nothing, unfortunately.  Also, if we can reuse those nodes, we'll win.
But, if you want to collect these, you could always collect only the
larger ones.  It could still be the case that the first 64 or so are
permanent.

    Richard>     I bet we could actually save significant memory in
    Richard> the compiler by reusing these nodes in more places than
    Richard> we do.  (For example, does `size_binop' give back one of
    Richard> the cached nodes if you add two small values?)

    Richard> Yes.  I did add *a lot* of places to those that reuse
    Richard> these recently.

Cool.

    Richard>     BTW, Kenner, it appears to me that half of the cache
    Richard> array is not used in size_int_type_wide.  Do you
    Richard> understand that code?

    Richard> I understand that code since I rewrote it recently.  And
    Richard> that " / 2" is definitely wrong and an artifact of the
    Richard> way it used to be!  I'll delete it in my sources and
    Richard> it'll come in soon.  Thanks for pointing it out.

Thanks.

    Richard> Perhaps all this ought to be replaced by a hash table
    Richard> anyway.

For speed, the small ones probably still should be linearly
addressable.  But, we should profile.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com