Tail call VM [2]

[arnaud-lb]

Related:

• This is the second part of Tail call VM #17849
• First part was Pass opline as argument to opcode handlers in CALL VM #17952

This part takes tail-calling and preserve_none from #17849:

• Opcode handlers dispatch directly to the next handler by tail-calling, which reduces function call overhead and avoids returning to the executor loop
• preserve_none reduces register saving overhead in opcode handlers

This also implements JIT support.

Non-dispatching opcode handlers

JIT needs non-dispatching opcode handlers (opcode handlers that return instead of calling the next one). I've tried two approaches for this:

• Generate a second, non-dispatching, variant of each handler. Use the variant as call_handler
• Use indirect dispatch similarly to the hybrid VM: zend_op->handler is a function that calls the real handler and dispatches.

I've tried both approach (the first one in this branch, and the second one in master...arnaud-lb:php-src:hybrid-tailcall.

The second approach resulted in a slightly slower VM due to indirect dispatching, and JIT generated more spilling when calling handlers as they clobber all registers.

Therefore I've taken the first approach in this PR.

A 3rd approach would be to control dispatching via an additional handler parameter, or to pass a dispatch function to handlers, but I suspect this would have been slower.

Fixed regs and preserved regs

Thanks to the preserve_none convention, JIT'ed code only has to preserve rbp, which reduces the size of prologue/epilogue. Instead of preserving it, I add it to the set of fixed registers, so it's not used. This results in faster code.

Also, quite conveniently, preserve_none receives its first arguments via registers that are callee-saved in sysv. Therefore we can use the arg1 and arg2 regs as our fixed registers. This avoids moving arg1 and arg2 to SP/IP in prologue, or setting arg1/arg2 when tail-calling other handlers.

Benchmarks:

Benchmark	Mode	vs base	vs gcc	vs valgrind
bench.php	JIT	-4%	-0%	-5%
bench.php	Non-JIT	-44%	+3%
symfony demo	JIT	-0%	-0%
symfony demo	Non-JIT	-2.8%	-0%

base: Clang build of master, wall time
gcc: GCC build of master, wall time
valgrind: Clang build of master, valgrind instructions

Conclusion: Clang builds are now as fast GCC builds on the Symfony Demo benchmark in both JIT and non-JIT modes.

Issues

• The preserve_none calling convention is documented as unstable. JIT would break if it changed. I suggest checking this at build time, and disabling this optimization (tailcalling + preserve_none) if preserve_none changed. Edit: added a configure check.
• Clang currently fails to build PHP when using preserve_none and ASAN, therefore we disable this if ASAN is enabled. Edit: This seems to be fixed in recent Clang versions.

UPGRADING

  . PHP binaries built with Clang>=19 are now as fast as binaries built with
    GCC. The performance of binaries built with other compilers has also
    improved considerably.

TODO

• x86
• aarch64
• IR PRs
• preserve_none configure check

[arnaud-lb]

Typed handler pointers in a few places to prevent confusion between orig handler and call handlers (zend_vm_opcode_handler_t / zend_vm_opcode_handler_func_t).

[arnaud-lb]

#19006

[arnaud-lb]

Tail-calling was not possible due to the extra arg in zend_jit_trace_counter_helper, so I removed it.

Alternative would be to define these handlers in IR, as we do for the hybrid JIT.

[dstogov]

I didn't understand why extra_arg became a problem

[arnaud-lb]

Clang ˋmusttailˋ disallows calling functions with a different signature. Presumably this is to garantee portability. This is discussed here: https://blog.reverberate.org/2025/02/10/tail-call-updates.html

[arnaud-lb]

@dstogov this is still a WIP, but I would like to have your opinion on this. This is the same ideas as #17849, but with JIT support which implies a few things described above. I would like your opinion before handling the items in the todo list.

[dstogov]

The idea makes sense and the benchmark results look promising.
It's also interesting how it affects the VM code size.

Unfortunately at this moment I can't review a huge path like this in all details.
Anyway, I think it makes sense to finalize and land it.

[dstogov]

C standard doesn't require returning content of struct in a pair of registers.
x86_64 ABI does this, but all other ABIs have to be checked (x86, Windows64, ...).

[arnaud-lb]

Indeed.

SysV amd64 and aarch64 return the struct via registers, but SysV i386 and MS ABI do not.

Tail calling is effectively only enabled on clang, so this should not be an issue on Windows, at least currently.

It is an issue on x86 however.

I've made the following changes:

• Added __attribute__((sysv_abi)) on handlers returning zend_vm_trampoline, when compiling with Clang on Windows, so the struct is returned via registers.
• Enable tail calling only on x86_64 and arm64 (Edit: preserve_none is not supported on x86 anyway)

[dstogov]

fixed_regs are the registers reserved for the register variables.
I remember there were some problems with RBP usage, but I don't remember the exact problem.

[arnaud-lb]

In this case I add the register only to prevent the RA from using it. This is less expensive than adding it to the set of preserved registers. The same thing is done for the HYBRID VM a few lines below.

[dstogov]

I didn't understand why extra_arg became a problem

[arnaud-lb]

@dstogov I've addressed all issues, and all necessary IR changes have been merged, so this branch is now ready to be reviewed again, and hopefully merged :)

Since your last review I've made the following notable change: As adding preserve_none to IR requires longer term changes, I took the decision to not rely on IR for calling preserve_none functions. Instead I call these functions with the default convention in JIT. Arguments are passed via fixed regs, and the return register is the same as the default convention. This is safe because we always tailcall these functions, and only from other preserve_none functions, therefore we don't need to care about preserving regs around these calls.