From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3505 invoked by alias); 9 Apr 2011 10:34:15 -0000 Received: (qmail 3381 invoked by uid 22791); 9 Apr 2011 10:34:14 -0000 X-SWARE-Spam-Status: No, hits=-2.2 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-gy0-f175.google.com (HELO mail-gy0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 Apr 2011 10:34:10 +0000 Received: by gyf1 with SMTP id 1so2478959gyf.20 for ; Sat, 09 Apr 2011 03:34:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.139.15 with SMTP id r15mr2112873ann.137.1302345249189; Sat, 09 Apr 2011 03:34:09 -0700 (PDT) Received: by 10.100.214.4 with HTTP; Sat, 9 Apr 2011 03:34:08 -0700 (PDT) In-Reply-To: <4D9F1D63.9010509@redhat.com> References: <4D9D56F4.3050203@gmail.com> <4D9F1D63.9010509@redhat.com> Date: Sat, 09 Apr 2011 10:34:00 -0000 Message-ID: Subject: Re: [gc-improv] Permanent vs function RTL obstack fix From: Steven Bosscher To: Jeff Law Cc: Laurynas Biveinis , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00681.txt.bz2 On Fri, Apr 8, 2011 at 4:36 PM, Jeff Law wrote: >>> 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. I don't think that's a fair comment, or a real concern. Unlike 20 years ago, GCC now has a reasonable idea of how long RTX objects live. I can think of only four states for RTX in memory: 1. RTL that lives throughout the compilation, things like shared constants. RTX objects in this group are only in GC memory now because one RTX object on GC-memory cannot point to a non-GC RTX object (the mark-and-sweep process expects all objects to be in GC memory). 2. RTL from back-end (re-)initialization. Stuff in this group should go on a permanent obstack that is only removed if the back end is re-initialized (e.g. for the MIPS back end, or for future multi-target support). 3. RTL per translation unit. I am not sure what falls in this class. Things like RTL for global variables maybe? RTL that may escape from functions? Apparently the latter happens with labels, I hope it only happens with nested functions, really. Got some insights to share here? ;-) 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. Jeff, few people from 20 years ago are still around, so perhaps you can help a bit to help make things are going in the right direction. ;-) Ciao! Steven