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

From: Date: Tue, 22 Oct 2019 09:54:25 +0000
Subject: Req #78270 [Com]: Usage of __vectorcall convention with FFI
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-223373@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=78270&edit=1 ID: 78270 Comment by: lisachenko dot it at gmail dot com 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: 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? Previous Comments: ------------------------------------------------------------------------ [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? ------------------------------------------------------------------------ [2019-07-22 10:56:25] cmb@php.net The following patch has been added/updated: Patch Name: override-zend-fastcall Revision: 1563792985 URL: https://bugs.php.net/patch-display.php?bug=78270&patch=override-zend-fastcall&revision=1563792985 ------------------------------------------------------------------------ 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

« previous php.bugs (#223373) next »