I wonder how much effect the CPU's register remapping has on these results. Also, they ran it on an ancient CPU, but I'm not sure how much that matters.
This is pretty meaningless without showing any assembly code. What does the inner loop for siphash look like? How many GPRs does it use? Where are the spills placed? What does perf say about any of this?
IMHO this may be because with hyper-restrictive calling convention or register budgets, the compiler typically resorts to writing explicit MOV or stack PUSH/POP instructions to free up space.
Because modern CPUs have hundreds of hidden physical registers, the CPU's Register Renaming unit looks at those forced stack move instructions, realizes they are just recycling the same local variables, and maps them to hidden hardware registers anyway. The CPU essentially executes the "stack spills" at the hardware register level, rendering the compiler's bad register constraints almost completely harmless.
Particularly the siphash result makes me think this is what is happening.
Unfortunately I don’t think there is a way to observe this as a consumer.
5 comments
[ 0.27 ms ] story [ 21.8 ms ] threadBecause modern CPUs have hundreds of hidden physical registers, the CPU's Register Renaming unit looks at those forced stack move instructions, realizes they are just recycling the same local variables, and maps them to hidden hardware registers anyway. The CPU essentially executes the "stack spills" at the hardware register level, rendering the compiler's bad register constraints almost completely harmless.
Particularly the siphash result makes me think this is what is happening.
Unfortunately I don’t think there is a way to observe this as a consumer.