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?
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 > >> > >> > > > >
