From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27983 invoked by alias); 15 Jun 2010 17:26:51 -0000 Received: (qmail 27951 invoked by uid 22791); 15 Jun 2010 17:26:49 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ksp.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.206) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Jun 2010 17:26:44 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 1D6F2F1066; Tue, 15 Jun 2010 19:26:42 +0200 (CEST) Date: Tue, 15 Jun 2010 17:37:00 -0000 From: Jan Hubicka To: Mark Mitchell Cc: Michael Matz , gcc-patches@gcc.gnu.org Subject: Re: Speed up genattrtab Message-ID: <20100615172641.GE10161@atrey.karlin.mff.cuni.cz> References: <4C17B61F.2030602@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C17B61F.2030602@codesourcery.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2010-06/txt/msg01534.txt.bz2 > Michael Matz wrote: > > > This speeds up genattrtab to be no time issue during bootstrap anymore. > > > The speed difference > > of the compiler is acceptable I think, actually even speeding up the > > compiler sometimes (probably cache effects, because the .text size of > > insn-attrtab is _much_ smaller) or being in the noise. > > I certainly see how this benefits us as GCC developers. But, it does > look like it has a negative effect on overall compile-time, even though > in some cases it helps a bit. The effect seems negative, in the > aggregate, though I didn't try to dump your table into a spreadsheet and > actually get a number out. I don't think we should help ourselves at > the expense of the user's experience. > > I happened to be talking to someone else this morning about this same > issue. Would it help just to organize the Makefile in such a way that > this file is being built first, so that on a parallel machine it's not > the last thing being built? This person observed that in many cases > make seems to wait to *start* building insn-attrtab until very late in > the build process, meaning that all the other cores are idle while it's > building. In WHOPR compilation we now partition the program based on source files (this is something I plan to revisit later), so we get partition that corresponds to insn-attrtab. WPA driver sorts units by size and feeds them to parallel make and insn-attrtab is still last on finishing build by quite long shot. This ignore time spent by genattrtab itself. So just reordering makefiles is not going to solve the problem. I also think insn-attrtab starts late because genattrtab takes long time to generate it. insn-attrtab on i386 also has one dominating function. With WHOPR this can be solved by better partitioning algorithm along with function splitting (I have prototypes of both the second I plan to contribute soon after some bugfixing). Honza > > Thanks, > > -- > Mark Mitchell > CodeSourcery > mark@codesourcery.com > (650) 331-3385 x713