Among other things, this test tries to run too few and too many rounds
of SHA256. In both cases, it is expecting an error, but that behavior
depends on the implementation:
* PHP's own implementation raises an error in either case
* libxcrypt raises an error in either case
* Older versions of glibc would clamp the number of rounds
to a valid amount (newer versions don't have libcrypt)
* Musl libc clamps values that are too low, but raises an error
for values that are too high
If PHP is built with --with-external-libcrypt, the musl implementation
above can be used. Even if libxcrypt is installed, PHP will notice
that no additional -lfoo flags are needed to use the crypt
implementation in musl. To pass on such a system, we must not test
for the "too few rounds" behavior.
* PHP-8.3:
NEWS for GH-14814
ext/standard/tests: strings/wordwrap_memory_limit_32bit.phpt has two outputs
ext/standard/tests: 32bit wordwrap tests aren't just for Windows
* PHP-8.2:
NEWS for GH-14814
ext/standard/tests: strings/wordwrap_memory_limit_32bit.phpt has two outputs
ext/standard/tests: 32bit wordwrap tests aren't just for Windows
It turns out that on a 32-bit system, this test can produce either the
"usual" expected output from the 64-bit test, OR the 32-bit-only
integer overflow message. We copy the dual expected outputs from
chunk_split_variation1_32bit.phpt to handle both cases.
This fixes an earlier commit that split the two tests based only on
the size of an int (32-bit versus 64-bit). The CI reveals that, at
least on a debug/zts build, the "64-bit" memory limit error (and not
the integer overflow error) is still produced.
The test in strings/wordwrap_memory_limit.phpt has a counterpart in
strings/wordwrap_memory_limit_win32.phpt. The two are conditional on
both the OS name and the size of an int (32- versus 64-bits).
A Gentoo Linux user has however reported that the 64-bit test fails on
a 32-bit system, with precisely the error message that the "win32"
test is expecting. I don't have any 32-bit hardware to test myself,
but I think it's reasonable to conclude that the OS name is not an
essential part of the test: it's simply 32- versus 64-bit.
This commit drops the conditionals for the OS name. Now one test will
be run on 32-bit systems, and the other on 64-bit systems, regardless
of the OS name.
Bug: https://bugs.gentoo.org/935382
In strings/chunk_split_variation1_32bit.phpt, we have a test that is
expected to fail on x32 with a possible integer overflow error. The
message reports the exact number of bytes -- a number big enough to
overflow an int on x32 -- stemming from a memory allocation in
chunk_split().
This number appears unpredictable, and is not the point of the test.
We replace it with %d to make the test independent of the allocation
details.
* zend_compile: Rename `string_placeholder_count` to `placeholder_count` in `zend_compile_func_sprintf()`
This is intended to make the diff of a follow-up commit smaller.
* zend_compile: Add support for `%d` to `sprintf()` optimization
This extends the existing `sprintf()` optimization by support for the `%d`
placeholder, which effectively equivalent to an `(int)` cast followed by a
`(string)` cast.
For a synthetic test using:
<?php
$a = 'foo';
$b = 42;
for ($i = 0; $i < 100_000_000; $i++) {
sprintf("%s-%d", $a, $b);
}
This optimization yields a 1.3× performance improvement:
$ hyperfine 'sapi/cli/php -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php' \
'/tmp/unoptimized -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php'
Benchmark 1: sapi/cli/php -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php
Time (mean ± σ): 3.296 s ± 0.094 s [User: 3.287 s, System: 0.005 s]
Range (min … max): 3.213 s … 3.527 s 10 runs
Benchmark 2: /tmp/unoptimized -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php
Time (mean ± σ): 4.300 s ± 0.025 s [User: 4.290 s, System: 0.007 s]
Range (min … max): 4.266 s … 4.334 s 10 runs
Summary
sapi/cli/php -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php ran
1.30 ± 0.04 times faster than /tmp/unoptimized -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php
* Fix sprintf_rope_optimization_003.phpt test expecation for 32-bit integers
* zend_compile: Indent switch-case labels in zend_compile_func_sprintf()
* Add GMP test to sprintf() rope optimization
* Add `%s` test case to sprintf() GMP test
* zend_compile: Add `zend_compile_rope_finalize()`
This just extracts the implementation as-is into a dedicated function to make
it reusable in preparation of a future commit.
* zend_compile: Use clearer parameter names for `zend_compile_rope_finalize()`
* zend_compile: Fix `zend_compile_rope_finalize()` for ropes containing a single constant string
Without this Opcache will trigger a use-after-free in
`zend_optimizer_compact_literals()`.
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
* zend_compile: Optimize `sprintf()` into a rope
This optimization will compile `sprintf()` using only `%s` placeholders into a
rope at compile time, effectively making those calls equivalent to the use of
string interpolation, with the added benefit of supporting arbitrary
expressions instead of just expressions starting with a `$`.
For a synthetic test using:
<?php
$a = 'foo';
$b = 'bar';
for ($i = 0; $i < 100_000_000; $i++) {
sprintf("%s-%s", $a, $b);
}
This optimization yields a 2.1× performance improvement:
$ hyperfine 'sapi/cli/php -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php' \
'/tmp/unoptimized -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php'
Benchmark 1: sapi/cli/php -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php
Time (mean ± σ): 1.869 s ± 0.033 s [User: 1.865 s, System: 0.003 s]
Range (min … max): 1.840 s … 1.945 s 10 runs
Benchmark 2: /tmp/unoptimized -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php
Time (mean ± σ): 4.011 s ± 0.034 s [User: 4.006 s, System: 0.005 s]
Range (min … max): 3.964 s … 4.079 s 10 runs
Summary
sapi/cli/php -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php ran
2.15 ± 0.04 times faster than /tmp/unoptimized -d zend_extension=php-src/modules/opcache.so -d opcache.enable_cli=1 test.php
This optimization comes with a small and probably insignificant behavioral
change: If one of the values cannot be (cleanly) converted to a string, for
example when attempting to insert an object that is not `Stringable`, the
resulting Exception will naturally not show the `sprintf()` call in the
resulting stack trace, because there is no call to `sprintf()`.
Nevertheless it will correctly point out the line of the `sprintf()` call as
the source of the Exception, pointing the user towards the correct location.
* zend_compile: Eagerly handle empty format strings in `sprintf()` optimization
* zend_compile: Add additional explanatory comments to zend_compile_func_sprintf()
* Add zero-argument test to sprintf_rope_optimization_001.phpt
---------
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
atoi()'s return value is actually undefined when an underflow or
overflow occurs. For example on 32-bit on my system the overflow test
which inputs "h2147483648" results in repetitions==2147483647 and on
64-bit this gives repetitions==-2147483648. The reason the test works on
32-bit is because there's a second undefined behaviour problem:
in case 'h' when repetitions==2147483647, we add 1 and divide by 2.
This is signed-wrap undefined behaviour and accidentally triggers the
overflow check like we wanted to.
Avoid all this trouble and use strtol with explicit error checking.
This also fixes a semantic bug where repetitions==INT_MAX would result
in the overflow check to trigger, even though there is no overflow.
Closes GH-10943.
On short strings, there is no difference in performance. However, for
strings around 10,000 bytes long, the AVX2-accelerated function is
about 55% faster than the SSE2-accelerated one.