{"id":303,"date":"2026-01-15T14:16:06","date_gmt":"2026-01-15T14:16:06","guid":{"rendered":"https:\/\/haco.club\/?p=303"},"modified":"2026-01-15T14:16:06","modified_gmt":"2026-01-15T14:16:06","slug":"tailcall-in-aarch64","status":"publish","type":"post","link":"https:\/\/haco.club\/?p=303","title":{"rendered":"Tailcall in AArch64"},"content":{"rendered":"\n

In AArch64 (ARM64), for a tail call to work, the current function must tear down its own stack frame<\/strong> before branching to the next function.<\/p>\n\n\n\n

If it didn’t, the stack would grow infinitely with every tail call, causing a stack overflow.<\/p>\n\n\n\n

Here is exactly how the “reuse” works at the assembly level, step-by-step.<\/p>\n\n\n\n

1. The Standard Mechanism<\/h3>\n\n\n\n

In a normal return, a function ends with an epilogue<\/strong> that restores registers and the stack pointer, followed by a ret<\/code> instruction. In a tail call, the compiler generates a special epilogue that does the cleanup but replaces ret<\/code> with a branch instruction (b<\/code> or br<\/code>).<\/p>\n\n\n\n

The Sequence:<\/strong><\/p>\n\n\n\n

    \n
  1. Restore Callee-Saved Registers:<\/strong> The function loads the saved Frame Pointer (x29<\/code>) and Link Register (x30<\/code>) from its stack frame back into the registers.<\/li>\n\n\n\n
  2. Pop the Stack (Deallocation):<\/strong> The function adds to the Stack Pointer (sp<\/code>) to reclaim the space it used. At this exact moment, the stack is arguably “reused”<\/strong> because the memory is now marked as free for the next<\/em> function to claim.<\/li>\n\n\n\n
  3. Jump (Branch):<\/strong> Instead of executing ret<\/code> (which jumps to x30<\/code>), the processor executes a direct jump (b target_func<\/code>) to the start of the next function.<\/li>\n<\/ol>\n\n\n\n

    2. Concrete Assembly Example<\/h3>\n\n\n\n

    Imagine Function A<\/code> calls Function B<\/code>, and Function B<\/code> tail-calls Function C<\/code>.<\/p>\n\n\n\n

    Function B (The Tail Caller):<\/strong><\/p>\n\n\n\n

    _FunctionB:\n    \/\/ --- Prologue ---\n    stp     x29, x30, [sp, #-16]!   \/\/ Push FP and LR\n    mov     x29, sp                 \/\/ Set up Frame Pointer\n\n    \/\/ ... do some work ...\n\n    \/\/ --- Tail Call Preparation ---\n    \/\/ 1. Restore the caller's context (Function A's context)\n    ldp     x29, x30, [sp], #16     \/\/ Pop FP and LR, and increment SP (deallocate frame)\n\n    \/\/ 2. The stack is now exactly as it was when A called B.\n    \/\/    SP points to A's frame. LR contains the return address back to A.\n\n    \/\/ 3. Jump to C\n    b       _FunctionC<\/code><\/pre>\n\n\n\n
    Function C (The Target):<\/strong>
    When Function C<\/code> starts, it sees the stack pointer (sp<\/code>) pointing to Function A<\/code>‘s frame. When Function C<\/code> finishes and executes ret<\/code>, it uses the value in x30<\/code> (LR). Since Function B<\/code> restored x30<\/code> before jumping, Function C<\/code> returns directly to Function A<\/code>.<\/p>\n\n\n\n
    3. The “Stack Argument” Limitation<\/h3>\n\n\n\n
    There is one major exception where this simple “pop before jump” strategy fails.<\/p>\n\n\n\n
    If Function C<\/code> (the target) takes more arguments on the stack<\/strong> than Function B<\/code> received, the tail call optimization is usually impossible (or very difficult).<\/p>\n\n\n\n
      \n
    • Why?<\/strong> Function B<\/code> would need to write new arguments into the stack space that belongs to Function A<\/code> (its caller), effectively corrupting the caller’s frame.<\/li>\n\n\n\n
    • Result:<\/strong> In this specific case, the compiler will disable Tail Call Optimization and use a standard call<\/code> (creating a new frame) instead.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
      In AArch64 (ARM64), for a tail call to work, the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[13,51],"class_list":["post-303","post","type-post","status-publish","format-standard","hentry","category-knowledge-base","tag-aarch64","tag-tailcall"],"_links":{"self":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/303","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=303"}],"version-history":[{"count":1,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/303\/revisions"}],"predecessor-version":[{"id":304,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/303\/revisions\/304"}],"wp:attachment":[{"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=303"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=303"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=303"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}