Comment 22 for bug 1882279

Verification steps:

on a clean focal/jammy installation, in a modern x86_64 (with v2/v3 capabilities) VM:
- installed php (without the proposed fix)
- ran the test script

focal: ~1.027
jammy: ~1.012

- installed php from the proposed pocket
- ran the test script

focal: ~0.135
jammy: ~0.136

on a clean focal/jammy installation, in a v1 x86_64 (no v2/v3 capabilities) VM:
- installed php (without the proposed fix)
- ran the test script

focal: ~1.037
jammy: ~1.020

- installed php from the proposed pocket
- ran the test script

focal: ~1.019
jammy: ~1.033

This shows that the fix improves the performance on v2/v3 capable machines without breaking php on v1 machines (covering test steps 1 and 2).

Next, we should show that the resolve_base64_decode path does not trigger calls to v2/v3 instructions on a v1 machine:

With gdb, for non-patched environments (jammy/focal), we verified that resolve_base64_decode, which is the function that resolves to the v2/v3 specific code, is not defined.

for patched environments (jammy/focal), we ran the test script with a break point in
resolve_base64_decode, which resolves to one of:

php_base64_dexode_ex_default;
php_base64_dexode_ex_avx2; or
php_base64_dexode_ex_ssse3.

We also set breakpoints to each of these functions.

We verified that in v2/v3 capable environments, resolve_base64_decode returns php_base64_dexode_ex_avx2 (v3). and php_base64_dexode_ex_avx2 is the only function called out of the three above.

For v1 environments, resolve_base64_decode returns php_base64_dexode_ex_default and the avx2/ssse3 functions are not called.

As far as we could verify with the data above, the fix is verified and introduce no regressions.