Re: GCC and SPARC leaf procedures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I obtained this:

40001168 <myleafp>:
40001168:    81 c3 e0 08     retl
4000116c:    01 00 00 00     nop

40001170 <main>:
40001170:    81 c3 e0 08     retl
40001174:    90 10 20 00     clr  %o0    ! 0 <_trap_table-0x40000000>

try the optimization -Os


George

Josef Ahmad wrote:
> No, I looked out for any kind of errors during the build of the cross-compiler version 3.4.4, I am quite sure the tools are well built. Moreover, the leaf optimization procedure is embedded with other back-end routines (I mean, they reside into the same source files) and if something went wrong during the build, the whole cross-compiler would have been broken.
>
> Well, I give you an example of the generated code with my gcc 3.4.4 cross-compiler (host: i686, target:sparc-elf). 
>
> - - - C source - - -
> void myleafp() { return; }
>
> int main(){
>   myleafp();
>   return 0;
> }
> - - -
>
> sparc-elf-gcc issued with -O0 and -O2 gives the same machine code:
>
> - - - obj dump - - -
> 40001170 <myleafp>:
> 40001170:    9d e3 bf 98     save  %sp, -104, %sp
> 40001174:    81 c7 e0 08     ret
> 40001178:    81 e8 00 00     restore
>
> 4000117c <main>:
> 4000117c:    9d e3 bf 98     save  %sp, -104, %sp
> 40001180:    7f ff ff fc     call  40001170 <myleafp>
> 40001184:    01 00 00 00     nop
> 40001188:    82 10 20 00     clr  %g1    ! 0 <_trap_table-0x40000000>
> 4000118c:    b0 10 00 01     mov  %g1, %i0
> 40001190:    81 c7 e0 08     ret
> 40001194:    81 e8 00 00     restore
> - - - 
>
> Does your disassembly show a leaf procedure optimization?
>
> Josef
>
> --- On Fri, 10/22/10, Jorge PEREZ <jorge.perez@xxxxxxxx> wrote:
>
>   
>> From: Jorge PEREZ <jorge.perez@xxxxxxxx>
>> Subject: Re: GCC and SPARC leaf procedures
>> To: "Josef Ahmad" <josef_ahm@xxxxxxxxx>, gcc-help@xxxxxxxxxxx
>> Date: Friday, October 22, 2010, 10:44 AM
>> No problem Josef,
>>
>> however, I have tested that with GCC 3.4.4 and I'm pretty
>> sure it does
>> the optimization there too. Maybe you had an error during
>> the
>> cross-compiler build?
>>
>>
>> PS: please always reply to the mailing list
>>
>>
>>
>>
>> Josef Ahmad wrote:
>>     
>>> Eh, you gave me the solution: I was using the version
>>>       
>> 3.4.4 of gcc.
>>     
>>> I've just tried to compile my source code with gcc
>>>       
>> 4.4.2 and the optimization works.
>>     
>>> It's kind of weird, because there is an implementation
>>>       
>> for the leaf procedures optimization even in the former
>> version, but perhaps it did not work yet.
>>     
>>> Now the problem is partially solved, because I am
>>>       
>> using a porting of gcc based on the version 3.4.4, and I
>> would like to know how to obtain a leaf procedure
>> optimization (if possible) on that version. Otherwise, I
>> think I have to plan to update the porting to a newest
>> version of gcc.
>>     
>>> Thank you!
>>>
>>> Josef
>>>
>>> --- On Fri, 10/22/10, Jorge PEREZ <jorge.perez@xxxxxxxx>
>>>       
>> wrote:
>>     
>>>    
>>>       
>>>> From: Jorge PEREZ <jorge.perez@xxxxxxxx>
>>>> Subject: GCC and SPARC leaf procedures
>>>> To: gcc-help@xxxxxxxxxxx
>>>> Cc: josef_ahm@xxxxxxxxx
>>>> Date: Friday, October 22, 2010, 10:03 AM
>>>> Hello Josef
>>>>
>>>> I was intrigued by your email since I actually
>>>>         
>> think that
>>     
>>>> GCC performs
>>>> the leaf procedure optimization as indicated by
>>>>         
>> the SPARC
>>     
>>>> V8 manual (
>>>> www.*sparc*.org/standards/*V8*.pdf p. 194)
>>>>
>>>> However, note that there are certain conditions
>>>>         
>> that must
>>     
>>>> be met in
>>>> order to allow such optimizations, quoting the
>>>>         
>> above
>>     
>>>> referenced manual:
>>>>
>>>> Some leaf procedures can be made to operate
>>>>         
>> without their
>>     
>>>> own register
>>>> window
>>>> or stack frame, using their callerâs instead.
>>>>         
>> This can be
>>     
>>>> done when the
>>>> candidate
>>>> leaf procedure meets all of the following
>>>>         
>> conditions13:
>>     
>>>> Contains no references to %sp, except in its SAVE
>>>> instruction
>>>> Contains no references to %fp
>>>> Refers to (or can be made to refer to) no more
>>>>         
>> than 8 of
>>     
>>>> the 32 integer
>>>> regis-
>>>> ters14, inclusive of %o7 (the âreturn
>>>>         
>> addressâ).
>>     
>>>> Actually there is a good example in a recent
>>>>         
>> thread
>>     
>>>> http://gcc.gnu.org/ml/gcc-help/2010-10/msg00249.html
>>>> where you can see that in the function "somme",
>>>>         
>> which I
>>     
>>>> think is a leaf
>>>> procedure, the SAVE and RESTORE instructions have
>>>>         
>> been
>>     
>>>> removed. What do
>>>> you think?
>>>>
>>>>
>>>> Otherwise, which GCC version are you using? I
>>>>         
>> don't think
>>     
>>>> that can be
>>>> related to that, but just to be sure.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> George
>>>>
>>>>
>>>>      
>>>>         
>>>        
>>>
>>>    
>>>       
>>
>>     
>
>
>
>
>   





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux