From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10266 invoked by alias); 10 Apr 2011 18:49:58 -0000 Received: (qmail 10257 invoked by uid 22791); 10 Apr 2011 18:49:58 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtp-100-sunday.noc.nerim.net (HELO mallaury.nerim.net) (62.4.17.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 10 Apr 2011 18:49:51 +0000 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by mallaury.nerim.net (Postfix) with ESMTPS id 49D4515345A; Sun, 10 Apr 2011 20:49:50 +0200 (CEST) Received: from glinka.lesours ([192.168.0.1]) by hector.lesours with smtp (Exim 4.74) (envelope-from ) id 1Q8zhP-0005gd-Hu; Sun, 10 Apr 2011 20:49:27 +0200 Date: Sun, 10 Apr 2011 18:49:00 -0000 From: Basile Starynkevitch To: Laurynas Biveinis Cc: Steven Bosscher , Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: [gc-improv] Permanent vs function RTL obstack fix Message-Id: <20110410204817.04d466bb.basile@starynkevitch.net> In-Reply-To: References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00713.txt.bz2 On Sun, 10 Apr 2011 21:27:10 +0300 Laurynas Biveinis wrote: > 2011/4/9 Steven Bosscher : > > 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. I respect a lot Laurynas' work, but my general personal feeling & wish is on the contrary that in the long term, more GCC data should be garbage collected, and that GCC's garbage collector should be better. However, I tend to believe that Laurynas cleanup on RTL could be helpful. And in the long run, I would imagine that making RTL data garbage collectable again would just be a matter of adding GTY annotations somewhere. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***