From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17530 invoked by alias); 22 Apr 2002 22:27:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17507 invoked from network); 22 Apr 2002 22:27:54 -0000 Received: from unknown (HELO amsfep15-int.chello.nl) (213.46.243.27) by sources.redhat.com with SMTP; 22 Apr 2002 22:27:54 -0000 Received: from chello.nl ([62.163.43.195]) by amsfep15-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20020422222753.JYCN1268.amsfep15-int.chello.nl@chello.nl>; Tue, 23 Apr 2002 00:27:53 +0200 Message-ID: <3CC48E69.B93BFD6D@chello.nl> Date: Mon, 22 Apr 2002 16:59:00 -0000 From: Segher Boessenkool Reply-To: segher@chello.nl X-Accept-Language: en MIME-Version: 1.0 To: thorpej@wasabisystems.com CC: Michel LESPINASSE , gcc list Subject: Re: GCC performance regression - its memset ! References: <20020421005718.GA16378@zoy.org> <20020422213222.GA21429@zoy.org> <20020422144125.S27275@dr-evil.shagadelic.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg01122.txt.bz2 Jason R Thorpe wrote: > > On Mon, Apr 22, 2002 at 02:32:22PM -0700, Michel LESPINASSE wrote: > > > gcc-3.1 snapshot is about twice slower than 2.95 on that test case, > > and for some reason the gprof output is bogus (it does not account for > > the time spent in memset), while it was not with 2.95. > > gprof doesn't see it because gcc is doing the memset inline, presumably; it > does this in certain cases where it knows the size at compile time. > > Try running your test with -fno-builtin. (I'm not suggesting this as a > fix for your performance issue, just as an explanation of why memset() is > invisible to gprof in your testcase). Erm, no. In the 2.95 case, GCC _did_ inline the memset(); that's why it showed up as 5.74 seconds in main(). In the 3.1 case, it was not inlined; gprof doesn't show you the time spent in libc, as libc is not compiled with profiling enabled. Inlined functions are never profiled separately. Linking statically will make gprof show you the time spent in shared library functions (but not the call graph to those); or you can link against a libc that was compiled with profiling enabled, so you get a call graph as well. Segher