Re: Saving extension semantic values from collection

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

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

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

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

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

    I suggest we change the specification of size_int (or create a related
    function) to indicate that numbers up to `2 * HOST_BITS_PER_WIDE_INT'
    are cached.  

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

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

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

    There ought to be some interface to get permanent small integers; that
    will be a memory win.

Small integers of a sizetype are the most common, but I agree it might
be good to generalize it.

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

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

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