This is necessary at least on Windows to be able to actually call the
function from a different module (in this case php8phpdbg.dll could not
be build).
Closes GH-16204.
* Implement JIT for ZEND_FETCH_STATIC_PROP_* and improve interpretation
* Revert incorrect change
* Use FASTCALL calling convention
* Use EMPTY_SWITCH_DEFAULT_CASE
* Move the loading of the property info into zend_jit_uninit_static_prop()
* Check VM interrupt while internal frame is on top
* Use tab instead of spaces
* fix frame used in interrupt and refactor
* remove unused failures for zend_jit_check_timeout
* Fix JIT support
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>
* Fix the missing store to vm_interrupt
* Rename new functions
* Special case zend_interrupt_function in JIT code
* refactor to use ZEND_VM_SET_OPCODE_NO_INTERRUPT
* Split atomic exchange into load + store
It is difficult to determine performance of atomics sometimes. In this
case, the separate load+store is still correct, and a load does not
cause a modification, and might be faster for some platforms than an
exchange. A load+store is slower than an exchange, but we're fine
trading the penalty to the slow path and keeping the happy path faster.
---------
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>
Inline the lookup whether a function is observed at all.
This strategy is also used for FRAMELESS calls. If the frameless call is observed, we instead allocate a call frame and push the arguments, to call the the function afterwards.
Doing so is still a performance benefit as opposed to executing individual INIT_FCALL+SEND_VAL ops. Thus, even if the frameless call turns out to be observed, the call overhead is slightly lower than before.
If the internal function is not observed at all, the unavoidable overhead is fetching the FLF zend_function pointer and the run-time cache needs to be inspected.
As part of this work, it turned out to be most viable to put the result operand on the ZEND_OP_DATA instead of ZEND_FRAMELESS_ICALL_3, allowing seamless interoperability with the DO_ICALL opcode.
This is a bit unusual in comparison to all other ZEND_OP_DATA usages, but seems to not pose problems overall.
There is also a small issue resolved: trampolines would always use the ZEND_CALL_TRAMPOLINE_SPEC_OBSERVER function due to zend_observer_fcall_op_array_extension being set to -1 too late.
We require valid code for compilation to succeed, but these paths should always
be guarded by OPx_TYPE checks and never execute. Add an assertion to verify.
Alignment is not necessary while calculating slots reserved for
zend_execute_data and _zend_vm_stack.
ZEND_STATIC_ASSERT ensures the correct alignment while code
compilation. Credit is to Ilija Tovilo.
PR: https://github.com/php/php-src/pull/10988
Signed-off-by: Tony Su <tao.su@intel.com>
Reviewed-by : Ilija Tovilo
Reviewed-by : Dmitry Stogov
Reviewed-by : Niels Dossche
`zend_uchar` suggests that the value is an ASCII character, but here,
it's about very small integers. This is misleading, so let's use a
C99 integer instead.
On all architectures currently supported by PHP, `zend_uchar` and
`uint8_t` are identical. This change is only about code readability.
The problem is that we're using the variable_ptr in the opcode handler
*after* it has already been destroyed. The solution is to create a
specialised version of zend_assign_to_variable which takes in two
destination zval pointers.
Closes GH-10524
