Re: Saving extension semantic values from collection

[Mark Mitchell <mark at codesourcery dot com>]

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

    Richard> that such integers will be known permanent!  Yes, we do
    Richard> cache them, but that's part of the *implementation* of
    Richard> size_int, not its *specification*.  

Unfortunately, it's now a defacto part of the specification -- there
are certainly other parts of the compiler that relied on this.  Even
in the days of obstacks, these things were known to be on the
permanent obstack, and front-ends relied on this fact.  

Your point is well taken, in general, but the idea that *these* things
are permanent is pretty well engrained.  I don't see any reason to
both collecting them -- there are so few of them that the savings
couldn't possible be a major win, right?

GCC's internal specifications are, shall we say, often unclear.  What
exactly is guaranteed is usually a superset of what is in the comments
for any particular function; it's exactly the question of *which*
implementation details were *meant* to be part of the specification
that makes much of the code difficult to deal with.

    Richard> The right approach, and one that I think we may have to
    Richard> do for other reasons anyway, is to make the trees in the
    Richard> parse stack visible to GGC.

Martin and I discussed this.  It's difficult to do, especially in a
way that's portable across both YACC and Bison.  Fortunately, it turns
out that almost nothing in the parse stack is not already rooted from
elsewhere.  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.

    Richard> Can you please revert this patch and do that instead?

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 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?)  There ought to be some interface to get
permanent small integers; that will be a memory win.

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?

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