This is interesting: the filename suggestssse43 sse42, but-mssse3 deemed sufficient.
Ups: edited typo.

Probably worth matching the filename, so that if an updated zlib-ng uses SSE4.3 instructions we don't need to modify anything here.

The file relies on intrinsics, so it's not going to automatically generate newer instructions.

I'd feel better we'd not enable that for all*.c files (at lest not onWin32). MSVC would be totally happy without it (and AFAIR defaults to SSE2 if not set). Maybe I'd then have to throw in more-m for clang-cl, but IMHO we're safer without that even in the MSVC case, so that the resulting binary can run on ancient CPUs, too.

Yeah, I suspect you're right on this. I'm not sure whether the intrinsics code is skipped or still generates fine without this, but it wouldn't surprise me if it's being ignored (there are__AVX*__ preprocessor checks that will behave differently without this setting).

Putting it just on the .c files fromarch\x86 should be enough. Those are already in a conditional ItemGroup, so the condition isn't needed each time (the ClangCL condition is, though).

Yeah, I suspect you're right on this. I'm not sure whether the intrinsics code is skipped or still generates fine without this, but it wouldn't surprise me if it's being ignored (there are__AVX*__ preprocessor checks that will behave differently without this setting).

Well spotted! Although MSVC allows you to use intrinsics even if the respective/arch part isn't set, it won't set the macros__AVX__, etc. Please note, that it never sets macros like__SSE2__:

• Fix #4265: Add appropriate compiler defines and flags for SIMD with MSVC AcademySoftwareFoundation/OpenImageIO#4266
• https://godbolt.org/z/3McojGzvs

Doing a regex__[A-Z]+[0-9]+__ only reveals

#  if (defined(X86_SSE2) && defined(__SSE2__)) || defined(__x86_64__) || defined(_M_X64) || defined(X86_NOCHECK_SSE2)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_functions.h7637#  if defined(X86_SSSE3) && defined(__SSSE3__)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_functions.h9537#if defined(X86_PCLMULQDQ_CRC) && defined(__PCLMUL__)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_functions.h11043#  if defined(X86_AVX2) && defined(__AVX2__)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_functions.h12336#  if defined(X86_AVX512) && defined(__AVX512F__) && defined(__AVX512DQ__) && defined(__AVX512BW__) && defined(__AVX512VL__)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_functions.h14738#    if defined(X86_AVX512VNNI) && defined(__AVX512VNNI__)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_functions.h15944#    if defined(__PCLMUL__) && defined(__AVX512F__) && defined(__VPCLMULQDQ__)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_functions.h16617

which are within an#ifdef DISABLE_RUNTIME_CPU_DETECTION, which isn't set.

The other hits are inx86_intrins.h:

#ifdef __AVX2__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h78#if (!defined(__clang__) && !defined(__NVCOMPILER) && defined(__GNUC__) && __GNUC__ < 10) \E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h1063#ifdef __AVX512F__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h188#endif // __AVX512F__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h2411#endif // __AVX2__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h2711#ifdef __AVX512F__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h318#if (!defined(__clang__) && !defined(__NVCOMPILER) && defined(__GNUC__) && __GNUC__ < 9)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h3263#endif // __AVX512F__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h6711#ifdef __AVX2__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h748#endif // __AVX2__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h7811#ifdef __AVX512F__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h808#endif // __AVX512F__E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h8411#if defined(_MSC_VER) && defined(__AVX512F__) && !defined(_MM_K0_REG8)E:\cpython_clang_pgo2\externals\zlib-ng-2.2.4\arch\x86\x86_intrins.h8834

where intrinsic quirks of some compiler versions are taken care of. There are some for MSVC that even include__AVX512F__, which wouldn't be covered with the currentAdvancedVectorExtensions2. My latest commits should fix this.

Putting it just on the .c files fromarch\x86 should be enough. Those are already in a conditional ItemGroup, so the condition isn't needed each time (the ClangCL condition is, though).

Yeah, I've only set it to those files that really need them, rendering some clang specific stuff obsolete :)

which are within an#ifdef DISABLE_RUNTIME_CPU_DETECTION, which isn't set.

This makes me quite confident, that you're spot on#131438 (comment)

I believe it's detected and called dynamically based on availability, but it's all compiled at compile time.

I.e., we are in the "dynamic dispatch" code path
https://github.com/zlib-ng/zlib-ng/blob/860e4cff7917d93f54f5d7f0bc1d0e8b1a3cb988/functable.h#L12-L26

#ifdefDISABLE_RUNTIME_CPU_DETECTION#  include"arch_functions.h"/* When compiling with native instructions it is not necessary to use functable. * Instead we use native_ macro indicating the best available variant of arch-specific * functions for the current platform. */#  defineFUNCTABLE_INIT ((void)0)#  defineFUNCTABLE_CALL(name) native_ ## name#  defineFUNCTABLE_FPTR(name) &native_ ## name#elsestructfunctable_s {

wherefunctable_s will be populated at runtime according to the capabilities of the CPU in:
https://github.com/zlib-ng/zlib-ng/blob/860e4cff7917d93f54f5d7f0bc1d0e8b1a3cb988/functable.c#L45-L49

staticvoidinit_functable(void) {structfunctable_sft;structcpu_featurescf;cpu_check_features(&cf);

Using the/arch option only for the needed files will now guarantee that the binary can run even on ancient CPUs and will use optimized code paths according to the CPU capabilites.

Using the/arch option only for the needed files will now guarantee that the binary can run even on ancient CPUs and will use optimized code paths according to the CPU capabilites.

This is similar to#130213 /#130447. Thus, I've checked using clang-cl 18.1.8: it is picky about just "seeing" intrinsics without the appropriate-m architecture - and it happily compiled :)

Since zlib-ng is compiled into a static lib, it won't produce any profile data. It is the first target that is built (after the_freeze_module)

IMHO, this is the best fix (instead of just settingSupportPGO=false for it):

• it still will get compiled with-fprofile-instr-generate
• it will be linked withpython314.dll and (hopefully?) happily contribute its part topython314.profraw
• MSVC doesn't createzlib-ng!1.pgc andzlib-ng.pgd either. No idea whether it gets PGOed there, but the same idea applies? The difference is just, that MSVC does not produce a hard error if the profile data isn't there, whereas clang does (TRACKEDEXEC : error : Error in reading profile profdata.profdata: no such file or directory), and I still have found no way to make that a warning :(

Since zlib-ng is compiled into a static lib, it won't produce any profile data.

Thinking about it again, instead of doing the-fno-profile-instr-use trick in thePGUpdate phase, it would be better, to just create the lib once instead of twice (like I've recently done for the_freeze_module).
There is no need to build the lib twice (same holds true for the MSVC case)?

I gave it a quick try:

• introducing aStaticLibProjects likeFreezeProjects inpcbuild.proj is simple and straight forward.
• Then I'd have to make theProjectReference Include="zlib-ng.vcxproj conditional (otherwise it would still be built in thePGUpdate phase) - ok, doable.
• but thenzlib.h is no longer found, because it is generated into$(IntDir)zlib.h - likewise$(IntDir)zlib-ng.h. So stopping here :)

So turns out to be not so easy and I'd like to keep that for a follow-up PR (if at all).

I assumed the call counts for PGO are going straight into each project that references it, since a static lib is essentially just a bundle of .obj files and so the link-time optimisation happens in the referencing project, not the static lib project.

Which means yes, it's participating in PGO, and it doesn't require rebuilding. Though it's not going to hurt that badly, so I'd tend towards decoupled build configuration (it would be easy to fix by moving the header file regeneration into pythoncore.vcxproj, but that's bad coupling).

Possibly we could makeSupportsPGO choose the definition ofIntDir and then it would usually be a quick rebuild?

Yeah, but let's do that in a follow-up PR, since it is not really related to clang-cl.

Technically, the/arch changes so that the resulting binary can run on legacy CPUs aren't either, but IMHO they are a nice fit here.

It would just put some rebase burden onto this PR, if we'd do it in a separate one.

Remember to remove