研究 PHP opcode 是如何优化的（二）

1、3）函数内联pass的实现

通常在函数调用过程中，由于需要进行不同栈帧间切换，因此会有开辟栈空间、保存返回地址、跳转、返回到调用函数、返回值、回收栈空间等一系列函数调用开销。因此对于函数体适当大小情况下，把整个函数体嵌入到调用者（Caller）内部，从而不实际调用被调用者（Callee）是一个提升性能的利器。

由于函数调用与目标机的应用二进制接口（ABI）强相关，静态编译器如GCC/LLVM的函数内联优化基本是在指令生成之前完成。

ZendVM的内联则发生在opcode生成后的FCALL指令的替换优化，pass id为16，其原理大致如下：

｜ 遍历op_array中的opcode,找到DO_XCALL四个opcode之一｜ opcode ZEND_INIT_FCALL｜ opcode ZEND_INIT_FCALL_BY_NAMEZ     ｜ 新建opcode，操作码置为ZEND_INIT_FCALL，计算栈大小，        更新缓存槽位，析构常量池字面量，替换当前opline的opcode｜ opcode ZEND_INIT_NS_FCALL_BY_NAME     ｜ 新建opcode，操作码置为ZEND_INIT_FCALL，计算栈大小，        更新缓存槽位，析构常量池字面量，替换当前opline的opcode｜ 尝试函数内联     ｜ 优化条件过滤 （每个优化pass通常有较多限制条件，某些场景下         由于缺乏足够信息不能优化或出于代价考虑而排除）        ｜ 方法调用ZEND_INIT_METHOD_CALL，直接返回不内联        ｜ 引用传参，直接返回不内联        ｜ 缺省参数为命名常量，直接返回不内联     ｜ 被调用函数有返回值，添加一条ZEND_QM_ASSIGN赋值opcode     ｜ 被调用函数无返回值，插入一条ZEND_NOP空opcode     ｜ 删除调用被内联函数的call opcode（即当前online的前一条opcode）

如下示例代码，当调用fname()时，使用字符串变量名fname来动态调用函数foo，而没有使用直接调用的方式。此时可通过VLD扩展查看其生成的opcode，或打开opcache调试选项(opcache.optdebuglevel=0xFFFFFFFF)亦可查看。

function foo() { }  $fname = 'foo';

开启debug后dump可看出，发生函数调用优化前opcode序列（仅截取片段）为：

ASSIGN CV0($fname) string("foo")  INIT_FCALL_BY_NAME 0 CV0($fname)  DO_FCALL_BY_NAME

INIT_FCALL_BY_NAME这条opcode执行逻辑较为复杂，当开启激进内联优化后，可将上述指令序列直接合并成一条DO_FCALL string(“foo”)指令，省去间接调用的开销。这样也恰好与直接调用生成的opcode一致。

2、4）如何为opcache opt添加一个优化pass

根据以上描述，可见向当前优化器加入一个pass并不会太难，大体步骤如下：

先向zend_optimize优化器注册一个pass宏(例如添加pass17)，并决定其优化级别。

在优化管理器某个优化pass前后调用加入的pass（例如添加一个尾递归优化pass），建议在DFA/SSA分析pass之后添加， 更多内容请参考《Liпux就该这么学》！ 因为此时获得的优化信息更多。

实现新加入的pass，进行定制代码转换（例如zendoptimizefunc_calls实现一个尾递归优化）。针对当前已有pass，主要添加转换pass，这里一般也可利用SSA/DFA的信息。不同于静态编译优化一般是在贴近于机器相关的低层中间表示优化，这里主要是在opcode层的opcode／operand相应的一些转换。

实现pass前，与函数内联类似，通常首先收集优化所需信息，然后排除掉不适用该优化的一些场景（如非真正的尾不递归调用、参数问题无法做优化等）。实现优化后，可dump优化前后生成opcode结构的变化是否优化正确、是否符合预期（如尾递归优化最终的效果是变换函数调用为forloop的形式）。

1、以下是对基于动态的PHP脚本程序执行的一些看法，仅供参考。

由于LLVM从前端到后端，从静态编译到jit整个工具链框架的支持，使得许多语言虚拟机都尝试整合。当前PHP7时代的ZendVM官方还没采用，原因之一虚拟机opcode承载着相当复杂的分析工作。相比于静态编译器的机器码每一条指令通常只干一件事情（通常是CPU指令时钟周期），opcode的操作数（operand）由于类型不固定，需要在运行期间做大量的类型检查、转换才能进行运算，这极度影响了执行效率。即使运行时采用jit，以byte code为单位编译，编译出的字节码也会与现有解释器一条一条opcode处理类似，类型需要处理、也不能把zval值直接存在寄存器。

以函数调用为例，比较现有的opcode执行与静态编译成机器码执行的区别，如下图：

2、类型推断

在不改变现有opcode设计的前提下，加强类型推断能力，进而为opcode的执行提供更多的类型信息，是提高执行性能的可选方法之一。

3、多层opcode

既然opcode承担如此复杂的分析工作，能否将其分解成多层的opcode归一化中间表示( intermediate representation, IR)。各优化可选择应用哪一层中间表示，传统编译器的中间表示依据所携带信息量、从抽象的高级语言到贴近机器码，分成高级中间表示（HIR） 、中级中间表示（MIR）、低级中间表示（LIR）。

4、pass管理

关于opcode的优化pass管理，如前文鲸书图所述，应该尚有改进空间。虽然当前分析依赖的有数据流／控制流分析，但仍缺少诸如过程间的分析优化，pass管理如运行顺序、运行次数、注册管理、复杂pass分析的信息dump等相对于llvm等成熟框架仍有较大差距。

5、JIT

ZendVM实现大量的zval值、类型转换等操作，这些可借助LLVM编译成机器码用于运行时，但代价是编译时间极速膨胀。当然也可采用libjit。