From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11204 invoked by alias); 11 Apr 2011 20:03:09 -0000 Received: (qmail 11195 invoked by uid 22791); 11 Apr 2011 20:03:08 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Apr 2011 20:03:03 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3BK32v4014830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Apr 2011 16:03:02 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p3BK32fB015349; Mon, 11 Apr 2011 16:03:02 -0400 Received: from [10.3.113.84] (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p3BK31ZG019742; Mon, 11 Apr 2011 16:03:01 -0400 Message-ID: <4DA35E74.1020506@redhat.com> Date: Mon, 11 Apr 2011 20:03:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Laurynas Biveinis CC: 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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/msg00798.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/10/11 12:27, 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. 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. The obvious solution is you copy the object, but then you have to be able to distinguish within the object, what fields point to other temporary objects vs permanent objects so that you can copy the referenced temporary objects, but not the permanent objects (other parts of the compiler may expect those permanent objects to be unique/shared). Not fun, not at all fun. Been there, done that. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNo150AAoJEBRtltQi2kC7Yb0H+gPB2ub86sbkGx0ee5ry1YYc ww222sMb+YP6wQ/fIxi/tYXdfxcouJ4/SuiC03tYNAwvfONZuQNrZKyEwu5cPXIh OMQYhV5pxDLfaRmpklBZWfYndStlWUYrmZAHPLI0zO5BCxgQaiZx/A6zjg6lPNY/ VnMKpdF1Tp0M03tJ1JNqMlTKrP5mkV/gAsjQVyjAM1DJntLYIqxqmm4tinaAJXUf pYDHecQgV/ZvngzCI8XydNZXEk/GnrcVCnyByO1BBLOzCom63+WXzXAGE9HPTOvj fNncNhOFz5rAzowiddngkoxlnPNGJKbuypprt/U5u17j91MlGADRDTkcapvI21A= =PwyX -----END PGP SIGNATURE-----