Comment author: @xavierleroy

Background info:

The SP adjustments around C calls that you observed are performed any time the C calling conventions dictate that some arguments are passed on stack or that stack space must be reserved by the caller. For x86-64 under Win64, 32 bytes of stack space must be reserved. Other processor/OS combinations have less demanding requirements.

Concerning the proposed change in code generation:

First, I think you're greatly exaggerating the costs of these stack adjustments. The call is not cheap, and the function that is called does nontrivial work. Two register arithmetic operations are cheap compared to this.

Second, it is a conscious decision to SP-adjust around C calls rather than integrate the extra space in the calculation of the stack frame size as you suggest. The reason is that doing what you suggest would increase stack usage in the presence of recursive calls. Consider:

let rec f x =
if then

else

With your suggestion, every stack frame for f is 32 bytes bigger, leading to stack overflow earlier. With the current OCaml approach, the 32 bytes of extra stack space exist only during the C call and don't show up in the recursion.

Conclusion:

Thanks, but no thanks.

Comment author: russ

Thank you for taking the time to take a look at this so quickly. I had not thought about the recursion aspect, you're absolutely right, it would be a bad idea to take extra stack space like that.

Still, I am noticing slower C calls between the Windows and Linux versions, particularly on the caml_modify write barrier function (as I said, it's 50% slower in a tight loop). The only major difference in the generated ASM was the SP modification, so I figured that was the cause. Maybe it's just MSVC doing a bad job optimizing the called C functions compared to GCC.