This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Saving extension semantic values from collection
- To: mark at codesourcery dot com
- Subject: Re: Saving extension semantic values from collection
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Mon, 20 Mar 00 12:38:41 EST
- Cc: gcc-patches at gcc dot gnu dot org
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.