Re: [gc-improv] Permanent vs function RTL obstack fix

[Jeff Law <law@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/10/11 12:27, Laurynas Biveinis wrote:
> 2011/4/9 Steven Bosscher <stevenb.gcc@gmail.com>:
>> 4. RTL per function. GCC expands one GIMPLE function at a time, and
>> the idea is to initialize the RTL obstack once when expanding starts,
>> let it grow until final, and blow it away after final. Unlike 20 years
>> ago, this obstack is never rolled back during RTL passes. This relies
>> on generating not too much garbage, but memory for per-function RTL
>> should be dwarfed by per-translation unit GIMPLE anyway.
> 
> Well, I have plans to see if it is worthwhile for pass like combine to
> rollback the function obstack to do away with scratch RTL. Of course
> this depends, on how much memory can be saved by doing this - in
> comparison to current GC.
One of the fundamental problems you have to watch out for when dealing
with scratch objects is how to handle the case when you belatedly
realize you want the object to have a longer lifetime.

The obvious solution is you copy the object, but then you have to be
able to distinguish within the object, what fields point to other
temporary objects vs permanent objects so that you can copy the
referenced temporary objects, but not the permanent objects (other parts
of the compiler may expect those permanent objects to be unique/shared).
   Not fun, not at all fun.  Been there, done that.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNo150AAoJEBRtltQi2kC7Yb0H+gPB2ub86sbkGx0ee5ry1YYc
ww222sMb+YP6wQ/fIxi/tYXdfxcouJ4/SuiC03tYNAwvfONZuQNrZKyEwu5cPXIh
OMQYhV5pxDLfaRmpklBZWfYndStlWUYrmZAHPLI0zO5BCxgQaiZx/A6zjg6lPNY/
VnMKpdF1Tp0M03tJ1JNqMlTKrP5mkV/gAsjQVyjAM1DJntLYIqxqmm4tinaAJXUf
pYDHecQgV/ZvngzCI8XydNZXEk/GnrcVCnyByO1BBLOzCom63+WXzXAGE9HPTOvj
fNncNhOFz5rAzowiddngkoxlnPNGJKbuypprt/U5u17j91MlGADRDTkcapvI21A=
=PwyX
-----END PGP SIGNATURE-----