From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17767 invoked by alias); 7 Dec 2012 10:34:54 -0000 Received: (qmail 17659 invoked by uid 22791); 7 Dec 2012 10:34:53 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Fri, 07 Dec 2012 10:34:44 +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 qB7AYiqB000851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Dec 2012 05:34:44 -0500 Received: from zalov.redhat.com (vpn1-4-240.ams2.redhat.com [10.36.4.240]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qB7AYgiH003262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2012 05:34:43 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id qB7AYgUV004467; Fri, 7 Dec 2012 11:34:42 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id qB7AYf1S004466; Fri, 7 Dec 2012 11:34:41 +0100 Date: Fri, 07 Dec 2012 10:34:00 -0000 From: Jakub Jelinek To: Steven Bosscher Cc: Richard Biener , GCC Patches Subject: Re: [patch] ree.c: don't abuse GTY Message-ID: <20121207103441.GT2315@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20121207095756.GS2315@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-12/txt/msg00474.txt.bz2 On Fri, Dec 07, 2012 at 11:25:38AM +0100, Steven Bosscher wrote: > Perhaps somewhere during the development of ree.c struct ext_cand was > GGC-allocated, in which case TODO_ggc_collect would make sense, to > collect the ext_cands (there can be many of them). But since ext_cands > are not GGC-allocated, the only garbage "produced" by ree.c is when it > removes redundant extensions (via delete_insn). This is typically only > a very small percentage of the instructions, so there isn't a lot of > garbage produced. That isn't the only garbage produced, it also updates the PATTERNs of various instructions with something different. Have you done any measurement on what kind of percentage of the instructions is modified, or is "very small percentage" just a guess? E.g. on x86_64 it changes quite a lot of instructions if I remember well. I'm not saying we can't live without GC collection after REE, just saying it isn't at all obvious. Jakub