From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9883 invoked by alias); 10 Apr 2011 18:23:36 -0000 Received: (qmail 9873 invoked by uid 22791); 10 Apr 2011 18:23: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:23:30 +0000 Received: by fxm19 with SMTP id 19so3825154fxm.20 for ; Sun, 10 Apr 2011 11:23:29 -0700 (PDT) Received: by 10.223.6.11 with SMTP id 11mr13117fax.92.1302459808962; Sun, 10 Apr 2011 11:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.81.75 with HTTP; Sun, 10 Apr 2011 11:22:28 -0700 (PDT) In-Reply-To: <4D9F1D63.9010509@redhat.com> References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> From: Laurynas Biveinis Date: Sun, 10 Apr 2011 18:23:00 -0000 Message-ID: Subject: Re: [gc-improv] Permanent vs function RTL obstack fix To: Jeff Law Cc: Steven Bosscher , gcc-patches@gcc.gnu.org, Richard Guenther Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/msg00710.txt.bz2 2011/4/8 Jeff Law : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/08/11 07:21, Laurynas Biveinis wrote: >> 2011/4/8 Steven Bosscher : >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0* stmt.c (label_rtx): Allocate RTX in perma= nent RTL memory. >>> >>> That looks strange, labels should be function specific, except >>> non-local labels. Maybe you can get away with allocating DECL_NONLOCAL >>> labels on the permanent rtl obstack? >> >> That's a good idea, I will try it once things are stable on the branch. >> >>> Perhaps a third, per-translation-unit obstack is necessary? >> >> Perhaps. After I finish with permanent rtl obstack, I will measure how >> large it gets and if it's worthwhile to split out >> per-translation-obstack out of it. > And then you'll want a per-statement obstack, then per-expression > obstack, and before you know it, GCC looks much like it did 20 years ago. It is certainly true that moving away from GC will make some kinds of bugs possible again, but I hope that not enough to be an unmanageable concern. The RTL object lifetimes seem to be clear in most of the instances and so far I am going with only two of them: permanent and function. After the initial conversion is done, I don't expect much trouble for any new RTL allocations introduced to be decided which memory area they belong to. Adding a third area, e.g. per-TU, of course would complicate this, but I still believe this is manageable. -- Laurynas