From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-289107-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12436 invoked by alias); 10 Apr 2011 18:27:36 -0000
Received: (qmail 12421 invoked by uid 22791); 10 Apr 2011 18:27:35 -0000
X-SWARE-Spam-Status: No, hits=-2.1 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Received: from mail-fx0-f47.google.com (HELO mail-fx0-f47.google.com) (209.85.161.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 10 Apr 2011 18:27:31 +0000
Received: by fxm19 with SMTP id 19so3826634fxm.20        for <gcc-patches@gcc.gnu.org>; Sun, 10 Apr 2011 11:27:30 -0700 (PDT)
Received: by 10.223.6.11 with SMTP id 11mr15494fax.92.1302460050108; Sun, 10 Apr 2011 11:27:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.81.75 with HTTP; Sun, 10 Apr 2011 11:27:10 -0700 (PDT)
In-Reply-To: <BANLkTi=FrbJbzkma-ySCbgGypM=wojJy4Q@mail.gmail.com>
References: <4D9D56F4.3050203@gmail.com> <BANLkTinA9APM95R4rf_9f93MTWeL+9MF8Q@mail.gmail.com> <BANLkTingEYhTGCRdXCch78KA40KfBW58CA@mail.gmail.com> <4D9F1D63.9010509@redhat.com> <BANLkTi=FrbJbzkma-ySCbgGypM=wojJy4Q@mail.gmail.com>
From: Laurynas Biveinis <laurynas.biveinis@gmail.com>
Date: Sun, 10 Apr 2011 18:27:00 -0000
Message-ID: <BANLkTimC9NWci-ZA+dVCu70wghVJKnKFeA@mail.gmail.com>
Subject: Re: [gc-improv] Permanent vs function RTL obstack fix
To: Steven Bosscher <stevenb.gcc@gmail.com>
Cc: Jeff Law <law@redhat.com>, gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-04/txt/msg00711.txt.bz2

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.

-- 
Laurynas