Hi Yo-An
On 04/11/2016 02:54 PM, Lin Yo-An wrote:
Hi Dmitry,
How's it going?
I traversed the code of opcache extension, and just found the
FUNC_INFO related macros. I guess the accessor information is more
like an entry that should be put in the function info.
That, FUNC_INFO is available only during optimization (it's especially
used in inter-procedure data-flow pass).
Or... maybe we shall move the function info related functions into the
core? since we might have some optimization based on the function info
instead of optimizing opcode only in the future.
We consider, possibility of moving the whole Optimizer into Zend, but it
won't change a lot, because expensive optimization make sense only with
opcache (when script is optimized once and executed many times).
And I think the function info we pre-processed in the compile-time
would help JIT to compile the opcode a lot.
Of course. Actually, the new optimization passes introduced in "master"
branch came from our zend-jit project and reused to generate LLVM code.
By the way, would you mind to let me know the plan of implementing the
JIT compilation in PHP? I saw your zend-jit branch is using LLVM as
the backend.
We don't have special plans yet. We are going to work on JIT later, and
now we mainly work on interpretative optimizations.
Once we start JIT, it's going to be much difficult to change something
in VM...
In my experience, LLVM compiles large code a lot of slower. what do
you think of using DynASM as the JIT backend?
Right. LLVM is not suitable for JIT. It's a compiler without front-end part.
We will probably go with DynASM from LuaJIT, Low Level Interpreter from
WebKit or our own similar approach.
V8 compiles ast nodes into native code directly without
interpreting/translating the op codes, I don't know if it's a good
approach to try. your thoughts?
In my experience, this approach doesn't work well especially with big
PHP applications.
Thanks. Dmitry.
Cheers, Yo-An
