RFC: https://wiki.php.net/rfc/null_coalesce_equal_operator
$a ??= $b is $a ?? ($a = $b), with the difference that $a is only
evaluated once, to the degree that this is possible. In particular
in $a[foo()] ?? $b function foo() is only ever called once.
However, the variable access themselves will be reevaluated.
Instead of interleaving creation of live-ranges with the main
compiler code, compute them in a separate pass over the opcodes
as part of pass_two. Additionally, do not keep live ranges
synchronized during optimization in opcache and instead use the
same mechanism to recompute them after optimization.
In f904830012, support for GNU Hurd was added to the opcache and
the configure check to ensure the opcache knows the flock struct
layout prior to building was changed check for two cases: BSD layout
and Linux layout. All the existing hard-coded cases in
ZendAccelerator.h follow these two cases, except for 64-bit AIX.
This means that even though building on 64-bit AIX would work,
the configure script refuses to continue.
Add a new configure check for the 64-bit AIX case and a new
compiler definition HAVE_FLOCK_AIX64. Now that all the cases are
covered, simplify the ifdef logic around these three HAVE_FLOCK_*
macros:
- The macOS and the various BSD flavors fall under HAVE_FLOCK_BSD
- Linux, HP-UX, GNU Hurd, 32-bit AIX, and SVR4 environments
fall under HAVE_FLOCK_LINUX
- 64-bit AIX falls under HAVE_FLOCK_AIX64
The only difference between the existing HAVE_FLOCK_LINUX and
the hard-coded Linux/HP-UX/Hurd case is that the latter
initialized the 5th member to 0, but since the C standard already
says that un-initialized members will be initialized to 0,
it's effectively the same.
Add MUL back to the list and instead make the entire optimization
depend on IGNORE_OVERLOADING, which is there exactly so we can make
these kinds of assumptions.
The cache size could be off by 4, if we're on a 32-bit system and
the slot had to be bumped for alignment reasons.
I wasn't able to reproduce the issue reported in bug #77287, but I
think this might be the cause.
Correctly handle the case of duplicate predecessors, by removing the
duplicate predecessor and corresponding phi node operands.
For the future, it would be better to instead allow duplicate
predecessors and avoid this kind of fragile code...
Instead of juggling with this problem during literal compaction,
make sure that we always initialize Z_EXTRA for literals, which
seems like the more robust solution.
Remove invalid assertion: A block can have multiple switch frees,
so if we don't do live range block splitting, it is not necessarily
true that the free is located at the start of a block.
Dmitry Stogov