Nikita Popov [Sat, 21 May 2016 22:05:06 +0000 (00:05 +0200)]
Improve previous fix
Do not mark loop var free blocks as reachable after all -- as we
can't construct SSA for unreachable blocks, this would cause
issues down the line.
Instead add an extra UNREACHABLE_FREE flag and retain only the
FREE instruction during NOP removal. (If we retain all
instructions in the BB we might leave a jump instruction that goes
into the nowhere.)
Nikita Popov [Tue, 17 May 2016 20:17:22 +0000 (22:17 +0200)]
Move builtin_ctzl portability into zend_bitset.h
Use this function in both zend_mm_bitset_find_one and
zend_bitset_first.
Maybe zend_bitset.h is not quite the right place for it, but I did
not want to include this in a globally included header like
zend_long.h or zend_portability.h.
Dmitry Stogov [Tue, 17 May 2016 05:45:06 +0000 (08:45 +0300)]
IS_CONST operands don't have to be separated. Use reference-counting instead of duplication.
- with opcache all IS_CONST operands are not refcounted (scalars, interned strings or immutable arrays)
- without opcache IS_CONST operands are not shared between processes or threads and may use common reference counters
Nikita Popov [Sat, 14 May 2016 11:54:41 +0000 (13:54 +0200)]
Inference: Fix undef handling for binary ops
We need to be careful about correctly handling that undef results
in a null value. Otherwise, apart from simply generating incorrect
results, we may also end up performing non-monotonic lattice
transitions, thus causing an infinite type inference loop (see
test).
Nikita Popov [Sat, 14 May 2016 11:03:25 +0000 (13:03 +0200)]
Fix & improve assign_dim inference
Extract a helper function for handling ASSIGN_DIM and ASSIGN_*
with ASSIGN_DIM ev uniformly. Previously the code was copy pasted
for each ASSIGN_* op, but the variable names were not correctly
adjusted (tmp vs orig), so the type inference result was wrong.
Also sligthly improve handling:
* Result cannot be false, will always be converted to array.
* If the dim is a CONST string operand, we don't have to assume
numeric strings.
* If the inserted value may be undef, the array may contain null.
Dmitry Stogov [Thu, 12 May 2016 22:40:15 +0000 (01:40 +0300)]
Eliminated checks for (func->op_array.fn_flags & ZEND_ACC_GENERATOR) in fast path of DO_FCALL* handlers.
This slightly improves calls to regular function and method calls in cost of a bit slower generator initialization.
Separate call frame for generators, allocated on heap, now created by ZEND_GENERATOR_CREATE instruction.
Nikita Popov [Thu, 12 May 2016 19:57:19 +0000 (21:57 +0200)]
Fix phi placement for pi targets
If the pi target has multiple predecessors, we need to place a
phi there. However it's not possible to express this in terms of
dominance frontiers, so we need to explicitly add it to the phi
set.
This does not yet solve the problem of non-minimal SSA for the
case where the target has multiple predecessors, but dominates
all predecessors (apart from the one creating the pi) -- but
that's an existing issue.
Nikita Popov [Thu, 12 May 2016 19:41:24 +0000 (21:41 +0200)]
Explicitly construct phi set during def propagation
Previously the phi set was first computed during def propagation
and then computed again (per-block) during actual phi placement.
This commit changes this to store the phi set computed during
def propagation.
This makes SSA construction slightly faster (5%), but the main
purpose here is to pave the way for the next commit.
This also fixes a potential issue with the handling of irreducible
loops -- they generated additional phis, but these were not
accounted for in def propagation. (Though I'm not sure if we can
even have any irreducible loops right now.)
Sara Golemon [Thu, 12 May 2016 02:28:57 +0000 (02:28 +0000)]
Fix serializing ZEND_AST_SHELL_EXEC
Currently, `foo` is reserialized as `'foo'` due to misuse of zend_ast_export().
ZEND_AST_SHELL_EXEC can only contain ZEND_AST_ZVAL(string) or ZEND_AST_ENCAPS_LIST,
so just handle the ZEND_AST_ZVAL(string) case directly.
Dmitry Stogov [Wed, 11 May 2016 21:44:18 +0000 (00:44 +0300)]
Use main VM stack for generators. Only single call frame for generator itself is allocated on heap, call frames for nested functions are allocated on main VM stack. In case "yield" used in context of another function call, call stack has to be frozen and then restored.