Any plan for Windows ARM64 MSVC support?

[m-miljkovic]

Is there any plan to support Windows ARM64 build with MSVC?

This could be used by numpy as windows ARM64 support is in progress #27330.

[jan-wassenberg]

Hi, currently there are no plans. If it is helpful for numpy we can consider it. One difficulty is that our internal support for MSVC is lacking. We'd have to rely on Github actions to test.

A perhaps bigger obstacle is that the arm_neon-inl.h implementation contains a few bits of inline assembly, which last I checked were not supported by MSVC. In my experience, the MSVC vector codegen has anyway fallen behind Clang and GCC. Is it not possible to use Clang or GCC instead?

[johnplatts]

The IsProcessorFeaturePresent function can be used on Windows on ARM64 to check for the presence of the AArch64 Crypto and DotProd instructions, and the IsProcessorFeaturePresent function is described at https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-isprocessorfeaturepresent.

It is possible to implement dynamic dispatch on Windows on ARM64, but HWY_NEON_WITHOUT_AES and HWY_NEON are the only NEON targets currently supported on Windows on ARM64 (at least when compiling with MSVC).

It is possible to check for SVE/SVE2 support on Windows on ARM64 with updated Windows SDK or mingw-w64 headers using IsProcessorFeaturePresent(PF_ARM_SVE_INSTRUCTIONS_AVAILABLE) or IsProcessorFeaturePresent(PF_ARM_SVE2_INSTRUCTIONS_AVAILABLE), but SVE/SVE2 C++ support on Windows on ARM64 requires compiling with Clang.

To implement dynamic dispatch on Windows on ARM64, the <windows.h> header needs to be included in 'hwy/targets.cc' on Windows on ARM64.

[Mugundanmcw]

Hi, currently there are no plans. If it is helpful for numpy we can consider it. One difficulty is that our internal support for MSVC is lacking. We'd have to rely on Github actions to test.

A perhaps bigger obstacle is that the arm_neon-inl.h implementation contains a few bits of inline assembly, which last I checked were not supported by MSVC. In my experience, the MSVC vector codegen has anyway fallen behind Clang and GCC. Is it not possible to use Clang or GCC instead?

@jan-wassenberg

Could you please provide more details on the specific support needed from MSVC to enable Highway QuickSort for NumPy? Specifically, could you list the intrinsic or inline assembly required to fully support the Highway implementation?

Thank you!

[johnplatts]

Hi, currently there are no plans. If it is helpful for numpy we can consider it. One difficulty is that our internal support for MSVC is lacking. We'd have to rely on Github actions to test.
A perhaps bigger obstacle is that the arm_neon-inl.h implementation contains a few bits of inline assembly, which last I checked were not supported by MSVC. In my experience, the MSVC vector codegen has anyway fallen behind Clang and GCC. Is it not possible to use Clang or GCC instead?

@jan-wassenberg

Could you please provide more details on the specific support needed from MSVC to enable Highway QuickSort for NumPy? Specifically, could you list the intrinsic or inline assembly required to fully support the Highway implementation?

Thank you!

hwy/ops/arm_neon-inl.h should compile with MSVC on ARM64 as the inline assembly code in hwy/ops/arm_neon-inl.h is only enabled when compiling with Clang.

[jan-wassenberg]

I agree arm_neon ought to compile with MSVC, because we do not attempt inline assembly with that compiler. But there is always some uncertainly when switching compilers and it may or may not work :)

One specific concern is how MSVC correctly handles IsNaN, where we had an assembly-language fallback due to strange clang codegen.