Add ZEND_INIT_ICALL instruction

[iluuu1994]

This avoids (compared to ZEND_INIT_FCALL):

• A pointer indirection, i.e. (char*)opline + opline->op2.constant vs (char*)execute_data->run_time_cache + opline->result.num
• A NULL check

Symfony Demo:

300 runs in seconds:

Before: 3.376795, 3.379392, 3.386662, 3.386701, 3.396124
After 3.344498, 3.358200, 3.361117, 3.361300, 3.365647

Fastest: 3.376795 vs 3.344498 = -0.96%
Mean: 3.3851348 vs 3.3581524 = -0.80%

Seems a bit high. 🤷‍♂️

[arnaud-lb]

Nice! This also avoids a hash lookup when the run time cache is not primed yet for a call site.

Could this be generalized to top level functions declared in the same file as the caller? Maybe to preloaded functions as well (not sure about that one).

[iluuu1994]

This also avoids a hash lookup when the run time cache is not primed yet for a call site.

Right, that too! That's likely the bigger factor that I didn't consider.

Could this be generalized to top level functions declared in the same file as the caller? Maybe to preloaded functions as well (not sure about that one).

Hmm, probably. The pointer will need to be fixed once the function is moved to shm. This might need a second pass, since functions can reference each other. I can have a look when this is merged. In that case though, it might make sense to rename this opcode.

[dstogov]

I see very slight speed improvement and I think it doesn't cost the current complexity of the patch.

Most probably this complexity may be significantly reduced.
For exampee instead of introduction of a new INIT_ICALL instruction, we may use a specialized handler for existing INIT_FCALL that relays on type of the constant operand (PTR instead of STRING).

May be we should even keep both STRING and additional PTR to reduce the fragmentation with Windows and simplify file cache support (it's missed now).

[iluuu1994]

Closed in favor of #13634.