From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15359 invoked by alias); 12 Apr 2011 11:56:31 -0000 Received: (qmail 15349 invoked by uid 22791); 12 Apr 2011 11:56:30 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 11:56:26 +0000 Received: (qmail 14688 invoked from network); 12 Apr 2011 11:56:25 -0000 Received: from unknown (HELO ?84.152.204.170?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Apr 2011 11:56:25 -0000 Message-ID: <4DA43D74.6080703@codesourcery.com> Date: Tue, 12 Apr 2011 11:56:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110325 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Jeff Law CC: Laurynas Biveinis , Steven Bosscher , gcc-patches@gcc.gnu.org Subject: Re: [gc-improv] Permanent vs function RTL obstack fix References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> <4DA35E74.1020506@redhat.com> In-Reply-To: <4DA35E74.1020506@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00859.txt.bz2 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