In place array modification

[nielsdos]

Benchmark script: https://gist.github.com/nielsdos/ae5a2dddc53c61749ae31c908aa78e98

This patch optimizes the $x = array_function($x, ...) pattern and the $x = array_function(temporary, ...) pattern for these functions: array_merge, array_unique, array_replace, array_diff and array_intersect.
With these limitations:

• no user-supplied callbacks as that runs code which may manipulate the array or may observe the side effect of this optimization.
• no SORT_STRING optimization for array_unique
• array_merge optimization works only if the array is packed and hole-less

Looking at the assembly of prepare_in_place_array_modify_if_possible() it looks pretty lightweight, about 91 bytes or 27 instructions on my x86-64 Linux laptop.

[nielsdos]

I see array_replace could maybe also benefit from this. It uses zend_array_dup just like array_unique. Maybe I can add a helper for this somewhere next week.

[nielsdos]

Added support for array_diff & array_intersect too, if they don't have a user-provided callback because in those cases we can't prove this optimization is safe and furthermore it could be observed by the callback. Although there it looks like other stuff dominates their runtime.

I also thought a bit about the safety of not taking a copy, because we're not increasing the refcount of the zval but the zval may be in the temporary lookup array if the function uses sorting. I think it's fine because:

• array_merge. No sorting or temporary array is used, so no need to increase refcount.
• array_replace. Same reasoning as array_merge, it even uses some common code paths.
• array_unique. Because cmpdata will never be removed so that will never reach refcount 0. And when something is removed, it is the previous value of cmpdata, not the one that will be used later.
• array_diff. It loops over the table from left to right and only accesses a destroyed pointer when behaviour==DIFF_NORMAL. But DIFF_NORMAL only happens when a user callback is set, which is when we don't use the optimization in this PR. So this is safe too.
• array_intersect. A previous pointer is accessed. But this can't be a destroyed pointer because the pointer is first moved forward in that code path.