Deciding when to sibcall

Deciding when to sibcall

[Paulo J. Matos]

Hello,

I have been trying to implement sibcalls (you can see my digression
yesterday in gcc-help) for an arch with gcc 4.3.4.
The problem with this is that I only want to sibcall when it happens
to reduce my code size.

I noticed (in the internals manual) we cannot actually fallback to a
normal call once we decide to sibcall through FUNCTION_OK_FOR_SIBCALL,
however, FUNCTION_OK_FOR_SIBCALL is called during expansion which
doesn't provide me with as much information as I need to choose
between sibcalling or not. The best timing would be when the epilogue
is generated, but this doesn't seem possible.

One example of the kind of information is if some registers are ever
live. This changes in some cases between the expand pass and the
pro_and_epilogue pass. As well as the framesize. All of this
information is important to have as a precise instrument to decide if
sibcall should actually be done.

Any suggestion on how to achieve this?

-- 
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net

Re: Deciding when to sibcall

[Dave Korn]

Paulo J. Matos wrote:

> The problem with this is that I only want to sibcall when it happens
> to reduce my code size.
> 
> I noticed (in the internals manual) we cannot actually fallback to a
> normal call once we decide to sibcall through FUNCTION_OK_FOR_SIBCALL,
> however, FUNCTION_OK_FOR_SIBCALL is called during expansion which
> doesn't provide me with as much information as I need to choose
> between sibcalling or not. The best timing would be when the epilogue
> is generated, but this doesn't seem possible.
> 
> One example of the kind of information is if some registers are ever
> live. This changes in some cases between the expand pass and the
> pro_and_epilogue pass. As well as the framesize. 

  Yep, this takes place during reload which iterates stack frame layout,
reload and spill generation and register elimination until it converges on a
stable solution.

> All of this
> information is important to have as a precise instrument to decide if
> sibcall should actually be done.
> 
> Any suggestion on how to achieve this?

  AFAIK the architecture of the compiler doesn't allow this and you are SOL.
The best you can probably do is try and come up with some reasonably effective
heuristics to make a best-guess at expand time whether or not you're likely to
want to sibcall by the time it all works out.

    cheers,
      DaveK

Re: Deciding when to sibcall

[Paulo J. Matos]

On Thu, Jan 7, 2010 at 5:29 PM, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> Paulo J. Matos wrote:
>
>> The problem with this is that I only want to sibcall when it happens
>> to reduce my code size.
>>
>> I noticed (in the internals manual) we cannot actually fallback to a
>> normal call once we decide to sibcall through FUNCTION_OK_FOR_SIBCALL,
>> however, FUNCTION_OK_FOR_SIBCALL is called during expansion which
>> doesn't provide me with as much information as I need to choose
>> between sibcalling or not. The best timing would be when the epilogue
>> is generated, but this doesn't seem possible.
>>
>> One example of the kind of information is if some registers are ever
>> live. This changes in some cases between the expand pass and the
>> pro_and_epilogue pass. As well as the framesize.
>
>  Yep, this takes place during reload which iterates stack frame layout,
> reload and spill generation and register elimination until it converges on a
> stable solution.
>
>> All of this
>> information is important to have as a precise instrument to decide if
>> sibcall should actually be done.
>>
>> Any suggestion on how to achieve this?
>

Thanks for the tip. I had thought about heuristic already but I was
trying to avoid such a 'non-precise' solution but I guess that's the
way I will go If there's no other path.


-- 
Paulo Jorge Matos - pocmatos at gmail.com
http://www.pmatos.net