Rather than using def_info, check against the actual arg_info type.
As it is stored as a type mask nowadays, this is not much harder,
but more general and more robust as we don't need to deal with
inaccurate cases.
* PHP-8.0:
Fix DCE of FREE of COALESCE
Note that this is a non-trivial merge, as opt/coalesce.phpt
regresses with this change. I'll have to see if it can be
improved.
When encountering the following SSA graph:
BB1:
#2.T1 [string] = COALESCE #1.CV0($str) [null, string] BB2
BB2:
#5.T1 [string] = QM_ASSIGN string("")
BB3:
#7.X1 [string] = Phi(#2.X1 [string], #5.X1 [string])
FREE #7.T1 [string]
We would currently determine that #7, #5 are dead, and eliminate
the FREE and QM_ASSIGN. However, we cannot eliminate #2, as
COALESCE is also responsible for control flow.
Fix this my marking all non-CV phis as live to start with. This
can be relaxed to check the kind of the source instruction, but
I couldn't immediately come up with a case where it would be
useful.
This handles the degenerate case where SCCP replaced the value in
the RETURN opcode with a constant, but the VERIFY_RETURN is still
there. We can still apply the same optimization, just don't need
to adjust the use list in this case.
The result is still sub-optimal in that a dead QM_ASSIGN is left
behind.
Even if we don't know the exact method being called, include it
in the call graph with the is_prototype flag. In particular, we
can still make use of return types from prototype methods, as
PHP 8 makes LSP violations a hard error.
Most other places are adjusted to skip calls with !is_prototype.
Maybe some of them would be fine, but ignoring them is conservative.
Even if an explicit return type is given, we might still infer
a more narrow one based on return statements. We shouldn't
pessimize this just because a type has been declared.
Some upcoming changes like https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
will make it somewhat inconvenient to determine whether a given
function invocation will generate a diagnostic. Rather than trying
to exclude this in advance, call the function with diagnostics
suppressed, and check whether anything was thrown.
This adds a new EG flag that is kept specific to the SCCP use-case.
This does not use the error_cb hook as it is a (non-TLS) global,
and doesn't fully suppress error handling besides.
Test this by removing the in advance checks for implode and array_flip.
Previously, two useless FE_RESET_R and FE_FREE would be left over whether the empty array
was from a literal, a variable, or a class constant.
This doesn't pick up the RESET_RW case due to a weakness in our "may throw"
modeling. (for foreach by reference).
Co-Authored-By: Nikita Popov <nikita.ppv@gmail.com>
using https://gist.github.com/nikic/58d367ad605e10299f5433d2d83a0b5b
Closes GH-4949
Replacing the result type in the general case is dangerous,
because not all opcodes support both VAR and TMP. One common case
is the in_array() result being passed to SEND_VAR, which would
have to be changed to SEND_VAL.
Rather than complicating this logic, reduce the scope to only
doing the type replacement for JMPZ and JMPNZ. The only reason
we're doing this in the first place is to enable the smart branch
optimization, so we can limit it to the relevant opcodes. Replacing
the result type may be marginally useful in other cases as well
(as it may avoid reference checks), but not worth the bother.
We should clear the exception *before* we destroy the execute_data.
Add a variation of the test that indirects through another file,
and would crash otherwise.
If the array is empty, then I'd expect that the generator is never left,
and that can be converted to a no-op and the return value would always be `null`.
Make `yield from [];` as efficient as `if (false) { yield null; }`
when opcache's sccp pass is enabled.
Closes GH-5679
After thinking about this a bit more, the code here was too
conservative. We know that everything but an object is going to
throw, so it's sufficient to restrict the type to MAY_BE_OBJECT.
The change in the test is weird but not incorrect, because it
operates on empty inferred types, in which case the code must be
dead (which it is). We should probably add a more explicit removal
of code working on empty types.
Place a pi node on the non-null edge to remove a spurious
undef/null type.
Additionally, adjust the profitability heuristic to be more
accurate if the "other predecessor" writes to the variable.
Ideally this should not just consider the direct predecessors,
but it's sufficient for this case.
This partially addresses bug #79353 by removing the discrepancy
between ?? and ??=.
Without the type hint the previous optimization no longer applied,
as the result could be an (overloaded) object, which might have
caused dtor effect reordering.
George Peter Banyard