This patch has no conflict with #12079

Benchmark shows a 1.59% regression for Zend/bench.php JIT. That benchmark is generally the most stable, so I would consider this legitimate. Symfony Demo and Wordpress show improvements (-0.65% and -0.07%, respectively).

Tracing over the already compiled function was done on purpose. This opens possibilities for new specializations and optimizations (similar to LuaJIT).

I'll take a look a bit later (probably next week). I think, the patch may be improved using a bit smarter heuristic - link to previous trace only if the trace of the inlined function become too long.

Tracing over the already compiled function was done on purpose. This opens possibilities for new specializations and optimizations (similar to LuaJIT).

I'll take a look a bit later (probably next week). I think, the patch may be improved using a bit smarter heuristic - link to previous trace only if the trace of the inlined function become too long.

Maybe we can add a parameter to link to the previous trace only if the trace of the inlined function becomes too long.
Or maybe we can add a switch for this patch?

Maybe we can add a parameter to link to the previous trace only if the trace of the inlined function becomes too long. Or maybe we can add a switch for this patch?

Yeah. You can of course. You may add something like opcache.jit_trace_inline_limit or opcache.jit_inline_over_link_limit.

Maybe we can add a parameter to link to the previous trace only if the trace of the inlined function becomes too long. Or maybe we can add a switch for this patch?

Yeah. You can of course. You may add something like opcache.jit_trace_inline_limit or opcache.jit_inline_over_link_limit.

Yeah, I tried it in my experiments. The smaller value opcache.jit_trace_inline_limit

Maybe we can add a parameter to link to the previous trace only if the trace of the inlined function becomes too long. Or maybe we can add a switch for this patch?

Yeah. You can of course. You may add something like opcache.jit_trace_inline_limit or opcache.jit_inline_over_link_limit.

I update this ~

@wxue1 could you please test the behaviour of your patch

test.php

<?php
class Foo {
 private $x = 0, $y = 0;
 function getX() {
 return $this->x * $this->x + $this->y * $this->y;
 }
}
$o = new Foo();
for ($i = 0; $i < 10; $i++) {
 $o->getX($i);
}
?>

$ sapi/cli/php -d opcache.jit=1254 -d opcache.jit_hot_func=2 -d opcache.jit_hot_loop=2 -d opcache.jit_trace_inline_func_limit=3 -d opcache.jit_debug=0x80000 test.php
---- TRACE 1 TSSA start (loop) $main() /home/dmitry/php/php-master/CGI-RELEASE-64/test.php:9
 ;#0.CV0($o) [!undef, ref, rc1, rcn, any]
 ;#1.CV1($i) [undef, ref, rc1, rcn, any]
LOOP:
 ;#3.CV1($i) [!undef, ref, rc1, rcn, any] = Phi(#1.CV1($i) [undef, ref, rc1, rcn, any], #13.CV1($i) [undef, ref, rc1, rcn, any])
0009 #4.T2 [bool] = IS_SMALLER #3.CV1($i) [!undef, ref, rc1, rcn, any] int(10) ; op1(int)
0010 ;JMPNZ #4.T2 [bool] 0005
0005 INIT_METHOD_CALL 1 #0.CV0($o) [!undef, ref, rc1, rcn, any] string("getX") ; op1(object of class Foo)
 >init Foo::getX
0006 SEND_VAR_EX #3.CV1($i) [!undef, ref, rc1, rcn, any] -> #5.CV1($i) [!undef, ref, rc1, rcn, any] 1 ; op1(int)
0007 DO_FCALL
 >enter Foo::getX
0000 #6.T0 [!long] = FETCH_OBJ_R THIS string("x") ; val(int)
0001 #7.T2 [!long] = FETCH_OBJ_R THIS string("x") ; val(int)
0002 #8.T1 [!long] = MUL #6.T0 [!long] #7.T2 [!long] ; op1(int) op2(int)
0003 #9.T0 [!long] = FETCH_OBJ_R THIS string("y") ; val(int)
0004 #10.T3 [!long] = FETCH_OBJ_R THIS string("y") ; val(int)
0005 #11.T2 [!long] = MUL #9.T0 [!long] #10.T3 [!long] ; op1(int) op2(int)
0006 #12.T0 [!long] = ADD #8.T1 [!long] #11.T2 [!long] ; op1(int) op2(int)
0007 RETURN #12.T0 [!long] ; op1(int)
 <back /home/dmitry/php/php-master/CGI-RELEASE-64/test.php
0008 PRE_INC #5.CV1($i) [!undef, ref, rc1, rcn, any] -> #13.CV1($i) [undef, ref, rc1, rcn, any] ; op1(int)
---- TRACE 1 TSSA stop (loop)

Your patch is intended to limit inlining of function above specified length (3), but it doesn't do it (function of length 8 is inlined). What is wrong?

For this case where the function is only inlined once, this patch allows inlining.
When more functions are inlined, eg A JIT compiled FuncA calls FuncB, this patch splits this trace and links to the FuncA.

I know you want to backtrack to FuncA as long as FuncB is too long whether or not the function has been JITTed.
I have tried and the code is here. patch1
Patch1 has some bugs when JITTed code calls other JITTed code, and it is a little hard to debug. Could you help take a look?

Or maybe we could return to the original easy code? patch2

Actually, this patch "Link to the compiled function to improve performance" is different from the previous patch about JIT long inline functions ( PR #10897 ) WordPress JIT Memory 1212kb -> 1019kb

This patch wants to fix this duplicated compiled inline function problem. In the picture, the apply_filters has been JITTed before, but it is still inlined.
I found many duplicated "apply_filters" inline functions in our workload WordPress. What do you think about that ?