From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8714 invoked by alias); 7 Dec 2012 10:26:24 -0000 Received: (qmail 8705 invoked by uid 22791); 7 Dec 2012 10:26:23 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-vb0-f47.google.com (HELO mail-vb0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Dec 2012 10:26:19 +0000 Received: by mail-vb0-f47.google.com with SMTP id e21so277909vbm.20 for ; Fri, 07 Dec 2012 02:26:19 -0800 (PST) Received: by 10.58.74.196 with SMTP id w4mr3552752vev.7.1354875979011; Fri, 07 Dec 2012 02:26:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.215.38 with HTTP; Fri, 7 Dec 2012 02:25:38 -0800 (PST) In-Reply-To: <20121207095756.GS2315@tucnak.redhat.com> References: <20121207095756.GS2315@tucnak.redhat.com> From: Steven Bosscher Date: Fri, 07 Dec 2012 10:26:00 -0000 Message-ID: Subject: Re: [patch] ree.c: don't abuse GTY To: Jakub Jelinek Cc: Richard Biener , GCC Patches 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: 2012-12/txt/msg00472.txt.bz2 On Fri, Dec 7, 2012 at 10:57 AM, Jakub Jelinek wrote: > I'd say removing the GTY(()) on a struct that is never GC allocated > nor interesting to PCH is obvious, the removal of TODO_ggc_collect is not > so. Right now it is set by passes that expect to potentially > create enough GC garbage that a collection might be desirable. > You haven't explained why you think it is the case of ree.c. You're right, I should have explained it. 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. I'll leave the TODO in place, and only remove the GTY marker from struct ext_cand. Ciao! Steven