Re: OP_TAILCALL versus OP_CALL question

[Jay Carlson <nop@...>]

Well, clang 3.4.1 on Ubuntu trusty targeting amd64 seems to generate the tail call/sibling call/whatever-they-call-it.

My guess is that the Linux amd64 ABI is always "fastcall" from the point of view of that documentation.

Jay

On Mar 21, 2015, at 6:03 PM, Pierre-Yves Gérardy <pygy79@gmail.com> wrote:

> The trouble is that you can't do that with LLVM.
> 
> It does support TCO, though, at the expense of easy C interop (you
> have to use incompatible calling conventions which breaks the ABI). As
> long as you don't want to mix C and Lua/Ravi code, FFI-style, you
> should be fine.
> 
> http://llvm.org/docs/CodeGenerator.html#tail-call-optimization
> http://llvm.org/docs/LangRef.html#calling-conventions
> —Pierre-Yves
> 
> 
> On Sat, Mar 21, 2015 at 4:23 PM, Coda Highland <chighland@gmail.com> wrote:
>> On Fri, Mar 20, 2015 at 3:25 PM, Dibyendu Majumdar
>> <mobile@majumdar.org.uk> wrote:
>>> On 20 March 2015 at 22:16, Doug Currie <doug.currie@gmail.com> wrote:
>>>>> I haven't yet figured out how to properly implement OP_TAILCALL in a
>>>>> JITed function.
>>>> 
>>>> 
>>>> The usual approach is to emit code to pop the stack frame and convert the
>>>> tail call to a jump.
>>>> 
>>> 
>>> In the recursive case, yes, but Lua also uses tail calls for
>>> non-recursive scenarios. For these a different function may be called
>>> so it is not possible to handle this in a JITed function - without
>>> replacing the function being executed as well.
>>> 
>>> Regards
>>> 
>> 
>> The technique still applies to the non-recursive case -- you still
>> clean up the stack frame, push on the return values, and jump.
>> 
>> /s/ Adam
>> 
>