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

[Bernd Schmidt <bernds@codesourcery.com>]

On 04/11/2011 10:03 PM, Jeff Law wrote:
> 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.

Historically, our problems with obstacks were a consequence of
line-by-line processing of the input file and never being quite certain
where a given object would have to end up. Almost all of that is simply
no longer an issue, which means RTL memory management is conceptually a
lot simpler than it used to be. A few things (constants, mostly) are
shared and must be permanent, the rest can go a single per-function
obstack which is freed after every function. I don't think we should (or
need to) try to have more obstacks for RTL.

I also don't see why a deep copy to the permanent obstack would be a
source of problems these days. More common than wanting to do that
however is the opposite case where you can speculatively generate RTL on
the function obstack, see if it's valid, and if not reset the obstack to
the earlier point to reclaim the memory. I know that reload and combine
could be made more efficient this way, and I'd guess the same is true
for fwprop.

I'd also like to point out that I share Steven's experience that the GC
stuff doesn't "just work"; I've certainly had objects collected from
under me and needed to puzzle out where to sprinkle the necessary GTY
markers.


Bernd