I checked something else, -O0 gives me this
40001168 <myleafp>:
40001168: 9d e3 bf 98 save %sp, -104, %sp
4000116c: 81 c7 e0 08 ret
40001170: 81 e8 00 00 restore
40001174 <main>:
40001174: 9d e3 bf 98 save %sp, -104, %sp
40001178: 7f ff ff fc call 40001168 <myleafp>
4000117c: 01 00 00 00 nop
40001180: 82 10 20 00 clr %g1 ! 0 <_trap_table-0x40000000>
40001184: b0 10 00 01 mov %g1, %i0
40001188: 81 c7 e0 08 ret
4000118c: 81 e8 00 00 restore
but -O2 gives the same as -Os, i.e.
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>
so I guess it's not normal that you don't obtain the optimization when
you use -O2
I confirm, I use sparc-elf 3.4.4
Cheers,
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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>
