From patchwork Thu May 10 22:45:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 158406 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]) by ozlabs.org (Postfix) with SMTP id D9AC2B6FA8 for ; Fri, 11 May 2012 08:46:31 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1337294792; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:User-Agent:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=6Xqq3ZXG3lQ5du8ZLeaBESQbOhQ=; b=Jde3Q2XSU3k6Png GcrD8dvXLrUC6iT3ORkZ09DcI8UAt/0Vmc5hsDCrUffvq13SB3egXAtA93M2l8x/ e5fgSVgeGJ5gQEEawzUADDi0fF9JuE7G9xOuHFBmImEtBw2xWNLwduuSxwkgII8t 3eutE3OM6Vw+Jk0vpt6M5GFEG4Ns= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=uhirKz3qr4rZGmqOGAVChUH4EmRtOnfkdKGn37W5A42a7kmUFZNmqdvqd7273/ yADEQ3NDyu9MnpmoW/Ugo0/v6pcx1xaJZwVqlzeGobSfOtD7BIs9lL0ZgoAkxc2R Vu43TbZ2GXK3OJTieGFsYSpah9DTSvocVYgz09kWXyMfk=; Received: (qmail 9206 invoked by alias); 10 May 2012 22:46:21 -0000 Received: (qmail 9185 invoked by uid 22791); 10 May 2012 22:46:18 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 May 2012 22:46:01 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id D30029AC8B2; Fri, 11 May 2012 00:45:57 +0200 (CEST) Date: Fri, 11 May 2012 00:45:57 +0200 From: Jan Hubicka To: gcc-patches@gcc.gnu.org Subject: Speed up inliner Message-ID: <20120510224557.GA1508@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) 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 Hi, this patch cuts 10 minutes of Mozilla compilation time that is spent by updating keys. After Richi's removal of overall growth from the cost functions, we no longer need to update that much. Bootstrapped/regtested x86_64-linux and tested on Mozilla build. Comitted. Honza * ipa-inline.c (update_all_callee_keys): Remove. (inline_small_functions): Simplify priority updating. Index: ipa-inline.c =================================================================== --- ipa-inline.c (revision 187375) +++ ipa-inline.c (working copy) @@ -1097,45 +1097,6 @@ update_callee_keys (fibheap_t heap, stru } } -/* Recompute heap nodes for each of caller edges of each of callees. - Walk recursively into all inline clones. */ - -static void -update_all_callee_keys (fibheap_t heap, struct cgraph_node *node, - bitmap updated_nodes) -{ - struct cgraph_edge *e = node->callees; - if (!e) - return; - while (true) - if (!e->inline_failed && e->callee->callees) - e = e->callee->callees; - else - { - struct cgraph_node *callee = cgraph_function_or_thunk_node (e->callee, - NULL); - - /* We inlined and thus callees might have different number of calls. - Reset their caches */ - reset_node_growth_cache (callee); - if (e->inline_failed) - update_caller_keys (heap, callee, updated_nodes, e); - if (e->next_callee) - e = e->next_callee; - else - { - do - { - if (e->caller == node) - return; - e = e->caller->callers; - } - while (!e->next_callee); - e = e->next_callee; - } - } -} - /* Enqueue all recursive calls from NODE into priority queue depending on how likely we want to recursively inline the call. */ @@ -1488,7 +1449,7 @@ inline_small_functions (void) at once. Consequently we need to update all callee keys. */ if (flag_indirect_inlining) add_new_edges_to_heap (heap, new_indirect_edges); - update_all_callee_keys (heap, where, updated_nodes); + update_callee_keys (heap, where, updated_nodes); } else { @@ -1527,18 +1488,7 @@ inline_small_functions (void) reset_edge_caches (edge->callee); reset_node_growth_cache (callee); - /* We inlined last offline copy to the body. This might lead - to callees of function having fewer call sites and thus they - may need updating. - - FIXME: the callee size could also shrink because more information - is propagated from caller. We don't track when this happen and - thus we need to recompute everything all the time. Once this is - solved, "|| 1" should go away. */ - if (callee->global.inlined_to || 1) - update_all_callee_keys (heap, callee, updated_nodes); - else - update_callee_keys (heap, edge->callee, updated_nodes); + update_callee_keys (heap, edge->callee, updated_nodes); } where = edge->caller; if (where->global.inlined_to) @@ -1551,11 +1501,6 @@ inline_small_functions (void) called by function we inlined (since number of it inlinable callers might change). */ update_caller_keys (heap, where, updated_nodes, NULL); - - /* We removed one call of the function we just inlined. If offline - copy is still needed, be sure to update the keys. */ - if (callee != where && !callee->global.inlined_to) - update_caller_keys (heap, callee, updated_nodes, NULL); bitmap_clear (updated_nodes); if (dump_file)