From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29504 invoked by alias); 15 Apr 2011 11:23:50 -0000 Received: (qmail 29493 invoked by uid 22791); 15 Apr 2011 11:23: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; Fri, 15 Apr 2011 11:23:44 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 8EFF7F062B; Fri, 15 Apr 2011 13:23:43 +0200 (CEST) Date: Fri, 15 Apr 2011 11:40:00 -0000 From: Jan Hubicka To: Richard Guenther Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: More of ipa-inline housekeeping Message-ID: <20110415112342.GC911@atrey.karlin.mff.cuni.cz> References: <20110413222034.GA12767@kam.mff.cuni.cz> <20110415092929.GB911@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: 2011-04/txt/msg01168.txt.bz2 > 2011/4/15 Jan Hubicka : > >> > > >> > I fixed this on the and added sanity check that the fields are initialized. > >> > This has shown problem with early inliner iteration fixed thusly and fact that > >> > early inliner is attempting to compute overall growth at a time the inline > >> > parameters are not computed for functions not visited by early optimizations > >> > yet. We previously agreed that early inliner should not try to do that (as this > >> > leads to early inliner inlining functions called once that should be deferred > >> > for later consieration).  I just hope it won't cause benchmarks to > >> > regress too much ;) > >> > >> Yeah, we agreed to that.  And I forgot about it as it wasn't part of the > >> early inliner reorg (which was supposed to be a 1:1 transform). > > > > Today C++ results shows some regressions, but nothing earthshaking.  So I think it is good > > idea to drop this feature of early inliner since it is not really systematic. > > There is also great improvement on LTO SPEC2000, but I tend to hope it is unrelated change. > > Perhaps your aliasing? > > I doubt SPEC2k uses VLAs or alloca, does it? Might be the DSE > improvements, but I'm not sure. It seems to happen only with LTO, so it might be inlining & fixed call cost estimates. It does not seem so likely to me however - I know that gzip is touchy about inlining, but vortex seems easy. Honza