Tail call elimination is straightforward if the tail call is to a function with a compatible stack parameter layout as the original function, since you can just replace the parameter slots on the stack with the new parameters. (The register-based parameters you can just overwrite directly in registers.)<\/p>\n
The obvious case where this applies is where the tail-calling and tail-called functions both have the same number of stack-based parameters. Just reuse the slots and jump to the next function.<\/p>\n
But you can also employ tail calling even if the number of stack-based parameters does not match exactly.<\/p>\n
One case where the tail call is possible is if the tail-called function has fewer parameters as the tail-calling function, and the calling convention is caller-clean. In that case, you can reuse the stack slots for the outbound parameters, and just leave any extra ones uninitialized. The tail-called function won’t use them, but the original caller will still clean them up. (Note that this doesn’t work in reverse: If the tail-called function has more<\/i> parameters than the tail-calling function, you can’t just smash the extra parameters onto the stack beyond those of the tail-calling function, because that’s writing into stack space that belongs to the original caller.)<\/p>\n
Here’s an example of a tail call on x86-32 to a function with fewer stack-based parameters.<\/p>\n
int __cdecl g(int c);\r\n\r\nint __cdecl f(int a, int b)\r\n{\r\n int v = helper(a, b);\r\n\r\n return g(a + b);\r\n \r\n}\r\n<\/pre>\nYou can reuse the stack space for the tail call to g<\/code><\/p>\n ; on entry, stack parameters are at [esp+4]\r\n ; and [esp+8]\r\n\r\n ; v = helper(a, b)\r\n push [esp+8]\r\n push [esp+8]\r\n call helper\r\n\r\n ; reuse the \"a\" slot for the outbound\r\n ; \"c\" slot\r\n mov [esp+4], eax\r\n\r\n ; tail call to g\r\n jmp g\r\n<\/pre>\nThe caller of f<\/code> will clean up two stack slots, and everything will return to normal. What the original caller doesn’t realize is that we reused one of them for g<\/code>, and the other still contains leftover data from f<\/code>. Logically, you can think that we inlined all of g<\/code> into f<\/code>.<\/p>\n