From patchwork Wed Feb 18 10:28:37 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Martin_Li=C5=A1ka?= X-Patchwork-Id: 440875 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 9F2911400B6 for ; Wed, 18 Feb 2015 21:28:50 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; q=dns; s=default; b=EGYq6R0vuW89MGyui NkiLOreyvmQ3DGlq3pPoJXPGpfLMAs+pbOFgYPlJGDe2hig2s2y/ZUUM7YiWlPli p7UA1tBITMWCvvbCsEccWwOiMJTcYzeoNBEuOJY74mNlen4F9FyEQh9t2c8oZDdC x9LUHDOvwzsqC+aVZTPEBnW85E= 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 :message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; s=default; bh=ED5kRADMvK99sYTlpmCNozc JIE4=; b=I8vj2vA5gpMP9F53t926OEYAs5MR3knioO0DCQ0mFPvHvYSlIqD9qf6 1FmwquXxRFTGWt5GTsm3g4hKYLCjqsLCMNUwnOyN8X3iCD6xClqY+l0Vt6a545vK jUTzlMnrEgyzZ9r8UAN5sDE88qpAyalYa37ficrQM1RrD9E91Kbw= Received: (qmail 32593 invoked by alias); 18 Feb 2015 10:28:44 -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 32575 invoked by uid 89); 18 Feb 2015 10:28:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 18 Feb 2015 10:28:42 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 34DAFAB12; Wed, 18 Feb 2015 10:28:38 +0000 (UTC) Message-ID: <54E46955.1040903@suse.cz> Date: Wed, 18 Feb 2015 11:28:37 +0100 From: =?windows-1252?Q?Martin_Li=9Aka?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jan Hubicka , GCC Patches Subject: Re: [RFC, PATCH] LTO: IPA inline speed up for large apps (Chrome) References: <54E376FC.9080709@suse.cz> <20150217183839.GA18175@atrey.karlin.mff.cuni.cz> In-Reply-To: <20150217183839.GA18175@atrey.karlin.mff.cuni.cz> X-IsSubscribed: yes On 02/17/2015 07:38 PM, Jan Hubicka wrote: > Hi, > thanks for working on it. There are 3 basically indpeendent changes in the patch > - The patch to make checking in lto_streamer_init ENABLE_CHECKING only that I > think can be comitted as obvoius. Hello. Following email contains fix for that, which I'm going to install. > - Templates for call_for_symbol_and_aliases > I do not think these should be strictly necessary for perofrmance, because once we > spent too much time in these we are bit screwed. > I however see it also makes things bit nicer by not needing typecasts on data pointer. > Pehraps that could be further cleaned? > > Alternative would be to implement FOR_EACH_ALIAS macro with tree walking iterator. > You have all the structure to not require stack. Iterator will ocntain an > root node, current node and index to ref. > This may be even easier to use and probably wind up generating about the same code > given that the for each template anyway needs to produce self recursive function. > > I would not care about for_symbol_thunk_and_aliases. That function is heavy by walking > all callers anyway and should not be used in hot code. > I have patch that removes its use from inliner - it is more or less leftover from time > we represented thunks as special aliases instead of functions w/o gimple body. Yes, I was also thinking about flat iterator that will be capable of iterating thunks/aliases and I prefer that approach compared to recursive functions. I think we can prepare it for next release, as you said it does not bring so much performance gain. > - the caching itself. > > I will look into the caching in detail. I am not quite sure I like the idea of exposing inline > only cache into cgraph.h. You could just keep the predicates as are, but have inline_ variants > in ipa-inline.h that does the caching for you. > > Allocating the bits directly in cgraph_node is probably OK, we don't really have shortage there > and can be revisited easily later... > > Honza > Please take a look at caching, it would be crucial part of speed improvement. Martin From eb9d34244c43ae1d0576b2ae1002f5267c6cd547 Mon Sep 17 00:00:00 2001 From: mliska Date: Wed, 18 Feb 2015 11:18:47 +0100 Subject: [PATCH] Add checking macro within lto_streamer_init. gcc/ChangeLog: 2015-02-18 Martin Liska * lto-streamer.c (lto_streamer_init): Encapsulate streamer_check_handled_ts_structures with checking macro. --- gcc/lto-streamer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/lto-streamer.c b/gcc/lto-streamer.c index 836dce9..542a813 100644 --- a/gcc/lto-streamer.c +++ b/gcc/lto-streamer.c @@ -319,11 +319,13 @@ static hash_table *tree_htab; void lto_streamer_init (void) { +#ifdef ENABLE_CHECKING /* Check that all the TS_* handled by the reader and writer routines match exactly the structures defined in treestruct.def. When a new TS_* astructure is added, the streamer should be updated to handle it. */ streamer_check_handled_ts_structures (); +#endif #ifdef LTO_STREAMER_DEBUG tree_htab = new hash_table (31); -- 2.1.2