This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM calling conventions generated in gcc with different optimizations


On 23/09/13 16:23, Vasily Golubev wrote:
> Thank you a lot for your answer, Mr. Radhakrishnan!
> 
> I think it was my mistake to use phrase "I will save LR at some
> place"... I mean I can catch the first instruction of any function
> precisely. And save LR value at that time to my local storage. And I
> also can catch the first instruction after exit from any function
> precisely. And will compare the address of this instruction with
> stored LR.
> 
> So, is it possible for gcc to generate code that will not save return
> address in LR before some call on ARM? Or it is forbidden?
> 

If the function never returns, then in theory the compiler may
effectively tail-call the function rather than setting up the return
address; but GCC doesn't normally do that today since it can make
debugging harder.  The ARM BL and BLX instructions automatically write
the return address into R14.  Most calls will use those instructions and
in other cases the behaviour is synthesized.

R.

> Vasily
> 
> On Mon, Sep 23, 2013 at 7:07 PM, Ramana Radhakrishnan
> <ramana.gcc@googlemail.com> wrote:
>>> And my main question is it possible to rely on this fact when
>>> compiling with gcc and different levels of optimizations?
>>
>> No it is not , the compiler (especially trunk) is free to use LR as a
>> temporary after epilogue has been generated at higher optimization
>> levels.
>>
>>
>>> Is it
>>> possible to generate some straightforward heuristic to detect this
>>> evens (with\without debug info)?
>>
>> With debug information you could in theory work this out but not
>> without it especially if LR were used as a temporary.
>>
>> regards
>> Ramana
>>
>>
>>>
>>> Thank you in advance for any suggestions!
>>>
>>> --
>>> Best Regards,
>>> Vasily
> 
> 
> 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]