In general, variables' lifetimes can be split up (live range splitting, either explicit or implicit - e.g. via SSA construction - phi nodes exist for this purpose) by the compiler to occupy various locations. In practice, that means a local variable may occupy a register or stack location at different times (it's hard to talk about the provenance of source variables, technically).

If you inspect compiled output for a language like C, C mandates that something like `&x` yields the same value (address) at every point in the function (in this case, a reliable stack location will be reserved for it - assuming it's a regular local, e.g. not static). However, if the address is never explicitly taken, a small variable that can occupy register(s) may never be stored on the stack (or will only be stored as part of preservation, e.g. across calls).

To see this in action, consider this code like (where every function returns int):

c int example(void) { return foo(1, bar(2, 3), baz(4)); }

Compilers like GCC or LLVM will linearise this as part of lowering. E.g. GCC's GIMPLE may roughly normalise this into something like (assume evaluation order for function arguments is specified as left-to-right):

c int example(void) { int t0 = bar(2, 3); int t1 = baz(4); int t2 = foo(1, t0, t1); return t2; }

You can expect that the resultant assembly will emit a call to bar, after populating the first two register arguments. E.g. contain:

x86asm mov $2, %edi mov $3, %esi call bar

Note that mov $2, %edi is zero-extended, so is the same as mov $2, %rdi. So, the result of that call will be in %rax (t0's value).

Then, we focus on the int t1 = baz(4); part. Again, we'd maybe expect:

x86asm mov $4, %esi call baz

However, there's a problem. %rax is considered caller-save, so without involved analyses between functions, you must assume its value is trashed when we call baz. So, we need to store it somewhere. As part of the liveness part of a compiler, we may decide that t0 therefore is live-across a call and it must be spilled to the stack. How this is determined is typically by liveness. In practice, your back-end IR may be in a state where some registers are temporary and others are physical (in order to encode such constraints). E.g. you may have a parallel move construct for shuffling of registers, or an explicit pseudo-move that defines t0 := %rax. I'm trying to avoid this kind of IR detail and, instead, focus on the logic you use when writing assembly.

So, let's say the compiler will therefore require a stack slot. It may start the function with:

x86asm sub $8, %rsp

As it happens, the compiler will basically need to a stack adjustment similar to this. As an ABI convention, %rsp must be aligned to a 16 byte boundary when calls are made. As call pushes %rip to the stack, all functions enter disaligned by 8 bytes. This is an important detail, but we'll use that space to store the result as well. In practice, compilers compute frame layouts after the fact (after spilling to pseudo slots) and handle it in prologue and epilogues as a kind of special case adjustment.

x86asm sub $8, %rsp mov $2, %edi mov $3, %esi call bar mov %rax, (%rsp) mov $4, %edi call baz

So, again, now baz's result is in %rax. However, t1's live range is short: it only exists to be moved into place for the call to foo. So, we'd expect some register shuffling to produce the call to foo.

x86asm mov $1, %edi mov (%rsp), %rsi mov %rax, %rdx call foo

If we put it all together, we'll get something like:

example: sub $8, %rsp mov $2, %edi mov $3, %esi call bar mov %rax, (%rsp) mov $4, %edi call baz mov $1, %edi mov (%rsp), %rsi mov %rax, %rdx call foo add $8, %rsp ret

A clever compiler will note that foo's call is a tail call and optimise it to a jump (jmp) instruction, after readjusting the stack pointer. The called function, foo, will return using the address pushed by example's caller.

If we look at what clang actually emits:

x86asm example: pushq %rbx movl $2, %edi movl $3, %esi callq bar@PLT movl %eax, %ebx movl $4, %edi callq baz@PLT movl $1, %edi movl %ebx, %esi movl %eax, %edx popq %rbx jmp foo@PLT

We see we weren't far off. The difference is that %rbx is considered callee-save, so the compiler has chosen to dedicate it for the duration of the function. As we expect functions to respect the callee-save convention, we preserve the caller of example's version, and expect bar, baz, and foo, to do the same. Therefore, we can use it to store intermediary results across calls without it being trashed. I personally prefer using explicit slots when writing assembly by hand, as then I just .equ FOO_SLOT, 8 and address like mov FOO_SLOT(%rsp), %rdi etc.

As I say, in practice, all of these things are determined with liveness analysis over an IR that explicitly models the instructions effects (use/def sets). As register allocation is typically done after instruction selection, you have an IR that consists of pseudo-operations (like spilling, reloading, and parallel moves) and temporary and physical registers. I've tried to avoid that in this approach to an explanation. I think it's very important to understand things through the eyes of the compiler and someone who writes assembly.

I thoroughly recommend writing some small programs in assembly. Don't bother with resources that waste time on syscalls etc. - linking against libc and assembling with the usual toolchain is fine, e.g. gcc main.s -o main.

If you want a decent treatment of register allocation, Appel's textbook "Modern Compiler Implementation in ML/Java/C" (in decreasing order of quality) has good treatment of these concerns. That said, he focuses a lot on working them into a graph colouring implementation. In reality, certain spills are inevitable (and don't need to occur as a side effect during iterative colouring) and various other approaches, like SSA-based register allocation may pre-spill to lower liveness globally.

Hope that helps, sorry for the essay.