From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4354 invoked by alias); 12 Mar 2008 06:51:16 -0000 Received: (qmail 4251 invoked by uid 48); 12 Mar 2008 06:50:34 -0000 Date: Wed, 12 Mar 2008 06:51:00 -0000 Message-ID: <20080312065034.4250.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/35544] Error with -fprofile-use In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pinskia at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00855.txt.bz2 ------- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-12 06:50 ------- For reference see: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01205.html http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00200.html http://gcc.gnu.org/ml/gcc/2005-12/msg00215.html And most likely a couple others too. I cannot find a good reference explaining why early inline helps a lot for C++ code like tramp3d. >Again, how much performance gain can be achieved with early optimization for instrumented binary (which is slow anyway)? IIRC there was a huge win (like a 10x speedup) for doing this. > At least it is tricky with cross module inlining happening for instrumented > functions -- the inline instances should really updating counters in the > original routines. Depends on if the inline is done with early inline or late and really really if it is done with late, the counters will be emitted with the LTO file before reading them back in so the counters will be correct already and inlining becomes obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35544