This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Questionable function renaming
On Tue, Jun 16, 2009 at 3:49 PM, Bingfeng Mei<bmei@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.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<bmei@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.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<bmei@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
>> >>
>> >>
>> >
>>
>>
>