Shower thought time... Internally, would it be faster to coerce args that would end up on the stack into a single block of malloc'd memory? Currently, our trampolines must perform a double-indirection to put data on the stack:
- load the pointer (something like
mov r15, [r14 + i*8]) to use a scratch register. - dereference that pointer to get the actual data (
mov rax, [r15]) - move the actual data to the destination register/stack slot (
mov rdi, rax)
With cache misses, longer arg lists (> 16?), etc. this is a choke point for speed (honestly, microseconds with millions of calls). Alternatively, if we let actual compiler designers deal with those and just allocate a single block of data that'll end up on the stack with something like sub rsp, #size, loop through all N args and call something like memcpy(block + offset, args[N], size); which would be more work being done in C but...
I'll have to benchmark moving our current data gathering step from the JIT path vs. having it done by actual compiler designers... For a 'typical' system this would be faster in theory but would it be faster enough to make it worth the work breaking all JIT generation code...