Saving extension semantic values from collection
Mon Mar 20 09:28:00 GMT 2000
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'
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
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.
More information about the Gcc-patches