MSVC ZEND_FASTCALL not portable?

[cmb69]

Description

When building with MSVC (or clang-cl), ZEND_FASTCALL is defined as __vectorcall. While __vectorcall is similar to the default x64 calling convention, and __fastcall on x86, respectively, there are notable differences. It seems to me that our JIT does not cater to these. That may still not be relevant to core functions, but could be an issue with external extensions which declare function as ZEND_FASTCALL.

Furthermore, there is definitely an issue regarding portability, since GCC doesn't support __vectorcall at all. While we do not necessarily support GCC on Windows, compatibility still seems to be a good thing.

Note that even __fastcall appears to be slightly different to the Windows __fastcall convention:

On x86-32 targets, the fastcall attribute causes the compiler to pass the first argument (if of integral type) in the register ECX and the second argument (if of integral type) in the register EDX. Subsequent and other typed arguments are passed on the stack.

The first two DWORD or smaller arguments that are found in the argument list from left to right are passed in ECX and EDX registers; all other arguments are passed on the stack from right to left.

This is possibly just a documentation issue (I haven't checked).

Anyhow, I suggest to change ZEND_FASTCALL with MSVC to use the default x64 calling convention for the x64 ABI; not sure what to suggest regarding x86.

cc @dstogov, @nielsdos, @arnaud-lb

PHP Version

PHP 8.4 (likely older)

Operating System

Windows

[arnaud-lb]

Note that even __fastcall appears to be slightly different to the Windows __fastcall convention:
[...]
This is possibly just a documentation issue (I haven't checked).

According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41013, they are not compatible. Checked on https://godbolt.org/z/4j753foYa, and indeed GCC differs at least when passing integers larger than int32 or structs (see calls to f4_3, f4_4, f4_7).

Anyhow, I suggest to change ZEND_FASTCALL with MSVC to use the default x64 calling convention for the x64 ABI; not sure what to suggest regarding x86.

This seems sensible to me. The alternative is to add __vectorcall support to IR and to the the frontend, but I'm not sure this is worth it.

For x86, the frontend already tells IR to use the fastcall convention when needed, so we should probably switch to fastcall on x86/Windows. I'm not sure whether IR is consistent with either GCC or MSVC, but I think it would make sense if IR added full compatibility with both.

[dstogov]

IR JIT definitely doesn't support __vectorcall, but it also doesn't support passing struct arguments and vecеor types, so this shouldn't be a problem. __fastcall should be the same for x86 SYSV and x86 WIN32, so this is not a problem for JIT as well.

I can't remember why we added _vectorcall, may be it's useful on Win32/64 for some functions where we pass short (size of word) structures.

[arnaud-lb]

@dstogov unless I'm mistaken, it appears that fastcall diverges on x86 SYSV vs x86 WIN32 when passing a int64: https://godbolt.org/z/8Excq4P31

[dstogov]

@arnaud-lb this is also not a problem for IR JIT, because it doesn't perform 64-bit operations on 32-bit systems.

[cmb69]

Okay, so there are no issues regarding JIT, but I'm still concerned about portability. I've just checked, and even MinGW gcc 14.2.0 doesn't understand __vectorcall, what appears to be a particular issue regarding the embed SAPI. If you have a embed.dll built with MSVC or clang-cl, you're not able to call any ZEND_FASTCALL function (directly from C), if you want to build your application with MinGW GCC. Might not be an issue in practice, but still it would be nice to support this scenario.

Furthermore, back then I've implemented partial support for __vectorcall in libffi, so users could call ZEND_FASTCALL functions via ext/ffi. That was completely faked; it doesn't even support float/double, let alone SIMD vectory types or HVAs. And there was no need to, because at least back then our ZEND_FASTCALL functions didn't use any float/double parameters, so there should be no drawback to use the standard calling convention on x64.

Only for x86, using __vectorcall may be an improvement (I was wrong before; we don't use __fastcall on x86 for ages), but I would argue that x86 on Windows is no longer really relevant (back then it has been; 64bit support in PHP 5 on Windows was experimental), so using __fastcall there shouldn't be much of an issue; except that perhaps there are some incompatibilites with GCC.

It seems I'm back to

Anyhow, I suggest to change ZEND_FASTCALL with MSVC to use the default x64 calling convention for the x64 ABI; not sure what to suggest regarding x86.

¯\(ツ)/¯

[dstogov]

I've just checked, and even MinGW gcc 14.2.0 doesn't understand __vectorcall, what appears to be a particular issue regarding the embed SAPI. If you have a embed.dll built with MSVC or clang-cl, you're not able to call any ZEND_FASTCALL function (directly from C), if you want to build your application with MinGW GCC. Might not be an issue in practice, but still it would be nice to support this scenario.

@cmb69 I wouldn't expect GCC and MSVC binary interopability independently from __vectorcall (Even binaries built with different MSVC versions are not compatible).