From patchwork Wed Jan 8 18:34:15 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 308395 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 105832C00B1 for ; Thu, 9 Jan 2014 05:34:28 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=LqxnCl0eyuy5CNaNI EOKbRvEgZtAXAJq2Cr8ZVckl18tXuHZEJ3Adz4rr58CNwLd2mSKtknGp9s49qj0y R929TRPHXpJ5RxeI9a1671lJXLlqY95m7lXTAl+wdIo/w/bbOF9ckbbEC1WysMJh FtzAY29azUg8V8QIjKaJ2/bT18= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=Uiy4HCHD9v3xrn746vjeW1Q jMrQ=; b=JzIgJfqk+/eogcVTfviyd1UbUApkkx+pQcnhpen387PT7+4JufDWvbJ rKRiZqZdAzg5YpxoFhqvHThlOpW/qkJ0qSe/lJxEyhXqK0hxZo9OuJW+JwDojboO YIbsKuWv77lBX1mbWNnEn1IHQPFWeFv/ruXJa3YMTENnOKYqmpBk= Received: (qmail 27531 invoked by alias); 8 Jan 2014 18:34:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 27516 invoked by uid 89); 8 Jan 2014 18:34:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Jan 2014 18:34:19 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s08IYHA5017875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Jan 2014 13:34:18 -0500 Received: from tucnak.zalov.cz (vpn1-6-194.ams2.redhat.com [10.36.6.194]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s08IYG4F029543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jan 2014 13:34:17 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.7/8.14.7) with ESMTP id s08IYFuG030547; Wed, 8 Jan 2014 19:34:15 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.7/8.14.7/Submit) id s08IYFJW030546; Wed, 8 Jan 2014 19:34:15 +0100 Date: Wed, 8 Jan 2014 19:34:15 +0100 From: Jakub Jelinek To: Richard Biener , Richard Sandiford Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Allocate all target globals using GC for SWITCHABLE_TARGETs Message-ID: <20140108183415.GK892@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <87iotxv211.fsf@talisman.default> <20140107193939.GY892@tucnak.redhat.com> <20140108124540.GG892@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140108124540.GG892@tucnak.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes On Wed, Jan 08, 2014 at 01:45:40PM +0100, Jakub Jelinek wrote: > I'd like to get rid of all the XCNEW calls in target-globals.c as a > follow-up. Here it is. The rationale is both to avoid many separate heap allocations and if TARGET_OPTION_NODE is no longer needed (all FUNCTION_DECLs referencing it are e.g. optimized away, say static unused functions) to avoid leaking memory. Bootstrapped/regtested on x86_64-linux and i686-linux (together with the i386 SWITCHABLE_TARGET patch). Though, looking at the sizes, i686-linux allocates 0x67928 bytes which I think with ggc-page.c we allocate 0.5MB for it (acceptable), on x86_64-linux the allocation size is 0x83aa8 and thus only ~ 15KB over to fit into 0.5MB, thus I think we allocate 1MB. So, if we wanted to tune for x86_64, we could not allocate say target_flag_state (size 0x5008) in the big chunk, but instead make it GTY((atomic)) and allocate separately. Or perhaps do that for other very large structs? In any case, that doesn't look like something that probably would need to be retuned for every release. The current sizes of the structs are: struct target_globals 0x80 0x40 struct target_flag_state 0x20 0x20 struct target_regs 0x5008 0x5008 struct target_hard_regs 0x35c8 0x33f8 struct target_reload 0xef70 0xef70 struct target_expmed 0x180b0 0xf4b0 struct target_optabs 0x4f0 0x4b9 struct target_cfgloop 0x1c 0x1c struct target_ira 0x9628 0x9620 struct target_ira_int 0x3fca8 0x322e4 struct target_lra_int 0xa718 0x4e70 struct target_builtins 0x268 0x268 struct target_gcse 0x62 0x62 struct target_bb_reorder 0x4 0x4 struct target_lower_subreg 0x24c 0x18c Perhaps use cut-off of 4KB with current sizes, anything below that would be allocated in the single block, anything above it separately. So 7 structs allocated together, 7 separately. 2014-01-08 Jakub Jelinek * target-globals.c (save_target_globals): Allocate most of the structs using GC in payload of target_globals struct instead of allocating them on the heap. Jakub --- gcc/target-globals.c.jj 2014-01-08 10:23:22.000000000 +0100 +++ gcc/target-globals.c 2014-01-08 14:00:13.183231122 +0100 @@ -68,24 +68,43 @@ struct target_globals * save_target_globals (void) { struct target_globals *g; - - g = ggc_alloc_target_globals (); - g->flag_state = XCNEW (struct target_flag_state); - g->regs = XCNEW (struct target_regs); + struct target_globals_extra { + struct target_globals g; + struct target_flag_state flag_state; + struct target_regs regs; + struct target_hard_regs hard_regs; + struct target_reload reload; + struct target_expmed expmed; + struct target_optabs optabs; + struct target_cfgloop cfgloop; + struct target_ira ira; + struct target_ira_int ira_int; + struct target_lra_int lra_int; + struct target_builtins builtins; + struct target_gcse gcse; + struct target_bb_reorder bb_reorder; + struct target_lower_subreg lower_subreg; + } *p; + p = (struct target_globals_extra *) + ggc_internal_cleared_alloc_stat (sizeof (struct target_globals_extra) + PASS_MEM_STAT); + g = (struct target_globals *) p; + g->flag_state = &p->flag_state; + g->regs = &p->regs; g->rtl = ggc_alloc_cleared_target_rtl (); - g->hard_regs = XCNEW (struct target_hard_regs); - g->reload = XCNEW (struct target_reload); - g->expmed = XCNEW (struct target_expmed); - g->optabs = XCNEW (struct target_optabs); + g->hard_regs = &p->hard_regs; + g->reload = &p->reload; + g->expmed = &p->expmed; + g->optabs = &p->optabs; g->libfuncs = ggc_alloc_cleared_target_libfuncs (); - g->cfgloop = XCNEW (struct target_cfgloop); - g->ira = XCNEW (struct target_ira); - g->ira_int = XCNEW (struct target_ira_int); - g->lra_int = XCNEW (struct target_lra_int); - g->builtins = XCNEW (struct target_builtins); - g->gcse = XCNEW (struct target_gcse); - g->bb_reorder = XCNEW (struct target_bb_reorder); - g->lower_subreg = XCNEW (struct target_lower_subreg); + g->cfgloop = &p->cfgloop; + g->ira = &p->ira; + g->ira_int = &p->ira_int; + g->lra_int = &p->lra_int; + g->builtins = &p->builtins; + g->gcse = &p->gcse; + g->bb_reorder = &p->bb_reorder; + g->lower_subreg = &p->lower_subreg; restore_target_globals (g); init_reg_sets (); target_reinit ();