Fix GH-15292: Dynamic AVX detection is broken for MSVC

[nielsdos]

See https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170 For x64, either _M_X64 or _M_AMD64 would work but I'm going with what's already used in php-src.

[cmb69]

Thank you! And yeah, I think these are the most appropriate macros here.

[cmb69]

I can confirm that with this patch now base64_encode() and mb_check_encoding() now use AVX implementation on x64 and x86 builds (while previously they didn't); I don't have an ARM available, so I can't check whether this works on ARM and ARM64EC.

For what it's worth, apparently dynamic AVX detection is only used for base64 and mbstring (plus the new SHA-NI which needs some changes to work on Windows); it may make sense to also use it where we currently only have compile time AVX detection (opcache and xxhash).

And we may consider to switch Windows CI to not use AVX2 to builds, so we can actually verify the dynamic AVX detection (and the regarding implementation), since now it occurs to me, that it might be best to stick with shipping only SSE(2) binaries for Windows (dynamic detection/resolution is likely a bit slower, but it's probably better not using AVX optimization where available, and probably better than having to choose between different Windows builds, or leaving some old processors unsupported).

[nielsdos]

I can confirm that with this patch now base64_encode() and mb_check_encoding() now use AVX implementation on x64 and x86 builds (while previously they didn't);

Thanks for checking

I don't have an ARM available, so I can't check whether this works on ARM and ARM64EC.

Shouldn't cause problems on ARM AFAICT, and ARM64EC can run x86-64 stuff so should be fine too.

it may make sense to also use it where we currently only have compile time AVX detection (opcache and xxhash).

Maybe, can we track that in a ticket?

And we may consider to switch Windows CI to not use AVX2 to builds, so we can actually verify the dynamic AVX detection (and the regarding implementation), since now it occurs to me, that it might be best to stick with shipping only SSE(2) binaries for Windows (dynamic detection/resolution is likely a bit slower, but it's probably better not using AVX optimization where available, and probably better than having to choose between different Windows builds, or leaving some old processors unsupported).

AVX2 is from 2013, so it's already 11y old now.
Letting users choose between Windows builds isn't a big deal imo, but I think it's mostly painful for the core developers and RMs to deal with more variants of Windows builds.

[nielsdos]

And I guess we should also track the backport of this maybe, once it has been proven to be okay.
I manually track backports in a TODO list, but that's not very convenient generally. Idk if there's a better system.

[cmb69]

Maybe, can we track that in a ticket?

I've filed #15315.

AVX2 is from 2013, so it's already 11y old now.

Do you suggest to ship AVX2 builds on Windows? So far we didn't even ship AVX builds, and the AVX snapshots are no longer available for years. And Pentium and Celeron processors only support AVX2 as of 2020, so some environments would no longer be supported.

Letting users choose between Windows builds isn't a big deal imo, but I think it's mostly painful for the core developers and RMs to deal with more variants of Windows builds.

Right.

And I guess we should also track the backport of this maybe, once it has been proven to be okay.
I manually track backports in a TODO list, but that's not very convenient generally. Idk if there's a better system.

Maybe an issue in this tracker with an appropriate milestone (something like 8.4.6 maybe).

[nielsdos]

Sorry I misunderstood your AVX2 build comment. I thought you meant offering both SSE2 and AVX2 builds. Indeed we should keep SSE2.

[cmb69]

Sorry I misunderstood your AVX2 build comment. I thought you meant offering both SSE2 and AVX2 builds.

I may have suggested that elsewhere/earlier, but dynamic AVX detection offers the most compatible solution. :)