From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8000 invoked by alias); 16 Jun 2009 14:34:39 -0000 Received: (qmail 7920 invoked by uid 22791); 16 Jun 2009 14:34:14 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Jun 2009 14:34:04 +0000 Received: from relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id CA96A93C3C; Tue, 16 Jun 2009 16:34:01 +0200 (CEST) Date: Tue, 16 Jun 2009 14:34:00 -0000 From: Martin Jambor To: Bingfeng Mei Cc: "gcc@gcc.gnu.org" Subject: Re: Questionable function renaming Message-ID: <20090616143400.GF27669@virgil.suse.cz> Mail-Followup-To: Bingfeng Mei , "gcc@gcc.gnu.org" References: <7FB04A5C213E9943A72EE127DB74F0AD93C5706309@SJEXCHCCR02.corp.ad.broadcom.com> <84fc9c000906160556h68b3ccf3k9b89ac8d0fd68211@mail.gmail.com> <7FB04A5C213E9943A72EE127DB74F0AD93C5706318@SJEXCHCCR02.corp.ad.broadcom.com> <84fc9c000906160602x243e7abo9ff7c7a1a4d3d5e7@mail.gmail.com> <7FB04A5C213E9943A72EE127DB74F0AD93C570632E@SJEXCHCCR02.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7FB04A5C213E9943A72EE127DB74F0AD93C570632E@SJEXCHCCR02.corp.ad.broadcom.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00368.txt.bz2 Hi, On Tue, Jun 16, 2009 at 06:49:58AM -0700, Bingfeng Mei wrote: > Thanks, I didn't notice both functions have different arguments after transformation. > However, gprof produces T.251 in its statistics, completely unknown > to user. Could GCC use more informative name here, e.g., saveInputFileMetaInfo.251? The current trunk (what is to become gcc 4.5) already gives clones a more sensible name, in your example it would be saveInputFileMetaInfo.clone.0 (IIRC). By the way, I work on allowing ipa-cp to produce multiple clones of a single function. Their names will differ in the number after the last dot. Martin > > 50.01 0.01 0.01 24 0.42 0.42 BZ2_hbMakeCodeLengths > 50.01 0.02 0.01 1 10.00 10.00 mainSort > 0.00 0.02 0.00 58 0.00 0.34 BZ2_bzCompress > 0.00 0.02 0.00 58 0.00 0.34 handle_compress > 0.00 0.02 0.00 43 0.00 0.34 BZ2_bzWrite > 0.00 0.02 0.00 6 0.00 0.00 BZ2_hbAssignCodes > 0.00 0.02 0.00 4 0.00 0.00 default_bzalloc > 0.00 0.02 0.00 4 0.00 0.00 default_bzfree > 0.00 0.02 0.00 2 0.00 0.00 addFlagsFromEnvVar > 0.00 0.02 0.00 2 0.00 0.00 myMalloc > 0.00 0.02 0.00 1 0.00 10.00 BZ2_blockSort > 0.00 0.02 0.00 1 0.00 0.00 BZ2_bzCompressInit > 0.00 0.02 0.00 1 0.00 5.17 BZ2_bzWriteClose64 > 0.00 0.02 0.00 1 0.00 0.00 BZ2_bzWriteOpen > 0.00 0.02 0.00 1 0.00 20.00 BZ2_compressBlock > 0.00 0.02 0.00 1 0.00 0.00 T.251 > 0.00 0.02 0.00 1 0.00 20.00 compress > 0.00 0.02 0.00 1 0.00 20.00 compressStream > 0.00 0.02 0.00 1 0.00 0.00 snocString > > Bingfeng > > > -----Original Message----- > > From: Richard Guenther [mailto:richard.guenther@gmail.com] > > Sent: 16 June 2009 14:02 > > To: Bingfeng Mei > > Cc: gcc@gcc.gnu.org > > Subject: Re: Questionable function renaming > > > > On Tue, Jun 16, 2009 at 3:01 PM, Bingfeng > > Mei wrote: > > > Is it possible to restore the original name if the copy > > propagation is not profitable and doesn't go ahead? > > > > The calling convention is changed, so I don't see how this is > > easily possible. > > > > Richard. > > > > >> -----Original Message----- > > >> From: Richard Guenther [mailto:richard.guenther@gmail.com] > > >> Sent: 16 June 2009 13:56 > > >> To: Bingfeng Mei > > >> Cc: gcc@gcc.gnu.org > > >> Subject: Re: Questionable function renaming > > >> > > >> On Tue, Jun 16, 2009 at 2:23 PM, Bingfeng > > >> Mei wrote: > > >> > Hello, > > >> > > > >> > I came across a function renaming issue in GCC 4.4. > > >> > > > >> > ~/work/install-x86/bin/gcc -Wall -Winline -O3 -g > > >> -D_FILE_OFFSET_BITS=64  -save-temps -c bzip2.c -fdump-tree-all > > >> > > > >> > > > >> > Function saveInputFileMetaInfo is renamed to T.251 after > > >> ipa passes, which are not dumped into intermediate files. So > > >> compare bzip2.c.038t.release_ssa and bzip2.c.049t.copyrename2 file, > > >> > > > >> > ;; Function saveInputFileMetaInfo (saveInputFileMetaInfo) > > >> > > > >> > Released 3 names, 50.00% > > >> > saveInputFileMetaInfo (Char * srcName) > > >> > { > > >> >  IntNative retVal; > > >> > > > >> > : > > >> >  retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo); > > >> >  if (retVal_4 != 0) > > >> >    goto ; > > >> >  else > > >> >    goto ; > > >> > > > >> > : > > >> >  ioError (); > > >> > > > >> > : > > >> >  return; > > >> > > > >> > } > > >> > > > >> > becomes > > >> > > > >> > ;; Function T.251 (T.251) > > >> > > > >> > T.251 () > > >> > { > > >> >  IntNative retVal; > > >> > > > >> > : > > >> >  retVal_1 = __xstat (1, &inName, &fileMetaInfo); > > >> >  if (retVal_1 != 0) > > >> >    goto ; > > >> >  else > > >> >    goto ; > > >> > > > >> > : > > >> >  ioError (); > > >> > > > >> > : > > >> >  return; > > >> > > > >> > } > > >> > > > >> > The renamed function stays afterwards. My understanding is > > >> that ipa-cp pass did copy-propagation of the original > > >> function but still somehow create a clone as suggested > > >> bzip2.c.203t.statistics. > > >> > > > >> > bzip2.c.203t.statistics:35 copyprop "Copies propagated" > > >> "saveInputFileMetaInfo" 1 > > >> > bzip2.c.203t.statistics:35 copyprop "Statements deleted" > > >> "saveInputFileMetaInfo" 3 > > >> > > > >> > This seems unnecessary and causes trouble in our > > >> profiling/debugging tools. I could diable this by using > > >> -fno-ipa-cp. But is there any better way? Thanks in advance > > >> > > >> It constant propagated &inName here (probably not very profitable > > >> as no further optimization is performed on the body) and removed > > >> the then unused parameter. > > >> > > >> Any better way to do what? > > >> > > >> Richard. > > >> > > >> > Cheers, > > >> > Bingfeng Mei > > >> > > > >> > Boradcom UK > > >> > > >> > > > > > > >