Req #78270 [Asn]: Usage of __vectorcall convention with FFI

Edit report at https://bugs.php.net/bug.php?id=78270&edit=1 ID: 78270 Updated by: cmb@php.net Reported by: lisachenko dot it at gmail dot com Summary: Usage of __vectorcall convention with FFI Status: Assigned Type: Feature/Change Request Package: Unknown/Other Function Operating System: Windows x64 PHP Version: 7.4.0alpha2 Assigned To: cmb Block user comment: N Private report: N New Comment: Failing to resolve zend_hash_add_or_update() has been tracked as bug #78716; since that bug has been fixed, new builds are available at <https://windows.php.net/downloads/snaps/ostc/ffi-vectorcall/>. Previous Comments: ------------------------------------------------------------------------ [2019-10-22 09:54:25] lisachenko dot it at gmail dot com Current patch helps a lot, at least most of __vectorcall functions can be resolved now. Surprisingly, extern zval __vectorcall *zend_hash_add_or_update(HashTable *ht, zend_string *key, zval *pData, uint32_t flag); could not be resolved, could you please check this? ------------------------------------------------------------------------ [2019-10-14 21:19:25] cmb@php.net There is now a dev version available[1], which adds minimal __vectorcall support (should be sufficient for PHP's APIs). It would be great if you could test it. [1] <https://windows.php.net/downloads/snaps/ostc/ffi-vectorcall/> ------------------------------------------------------------------------ [2019-07-25 10:42:08] cmb@php.net Well, the best solution would be to support __vectorcall, since there may be other libraries which use this calling convention. I tried to assess the required effort for this, and found that apparently no name mangling is yet supported by ext/ffi, so that even __fastcall wouldn't work on x86. This has to be resolved anyway. ------------------------------------------------------------------------ [2019-07-22 12:29:29] lisachenko dot it at gmail dot com Unfortunately, recompiling PHP with custom ZEND_FASTCALL doesn't change anything. Nobody will do this for general purposes, so in my opinion, we shouldn't affect overall performance by dropping this call convention, as it is a step back. However I have an interesting idea. What if we could solve this in another way, by defining all internal API functions as ZEND_FASTCALL and removing ZEND_API macros for them, thus they won't be exposed outside. And select some useful methods to work with internal structures with ZEND_API, but without declaring them as ZEND_FASTCALL convention. I can see some conflicts in presence of both ZEND_API and ZEND_FASTCALL. Because in some places the macros ZENA_API is present and in another it is absent, like with ZEND_FASTCALL. ------------------------------------------------------------------------ [2019-07-22 10:56:28] cmb@php.net I don't see a good *general* solution here. Assuming that #define ZEND_FASTCALL __vectorcall yields a more performant binary than #define ZEND_FASTCALL, we would have to sacrifice performance for the supposedly rare case when someone wants to use such functions via FFI. A compromise might be to let the configuration override the definition in zend_portability.h, e.g. something like the attached patch, so it would be possible to do set CFLAGS=/D ZEND_FASTCALL= & configure … Would that be sufficent for you, Alexander, or would you want the official binaries to be built without __vectorcall? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78270 -- Edit this bug report at https://bugs.php.net/bug.php?id=78270&edit=1