On Tue, Jun 16, 2009 at 3:49 PM, Bingfeng Mei<b...@broadcom.com> 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?
Probably we should set the clones abstract origin appropriately and gprof should use debug information to show that instead ... Richard. > 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.guent...@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<b...@broadcom.com> 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.guent...@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<b...@broadcom.com> 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; >> >> > >> >> > <bb 2>: >> >> > retVal_4 = __xstat (1, srcName_1(D), &fileMetaInfo); >> >> > if (retVal_4 != 0) >> >> > goto <bb 3>; >> >> > else >> >> > goto <bb 4>; >> >> > >> >> > <bb 3>: >> >> > ioError (); >> >> > >> >> > <bb 4>: >> >> > return; >> >> > >> >> > } >> >> > >> >> > becomes >> >> > >> >> > ;; Function T.251 (T.251) >> >> > >> >> > T.251 () >> >> > { >> >> > IntNative retVal; >> >> > >> >> > <bb 2>: >> >> > retVal_1 = __xstat (1, &inName, &fileMetaInfo); >> >> > if (retVal_1 != 0) >> >> > goto <bb 3>; >> >> > else >> >> > goto <bb 4>; >> >> > >> >> > <bb 3>: >> >> > ioError (); >> >> > >> >> > <bb 4>: >> >> > 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 >> >> >> >> >> > >> >> >
