Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSVC compile error for NEON (win/arm64) #611

Open
niyas-sait opened this issue Oct 19, 2021 · 3 comments
Open

MSVC compile error for NEON (win/arm64) #611

niyas-sait opened this issue Oct 19, 2021 · 3 comments

Comments

@niyas-sait
Copy link

XSIMD library cannot be built using MSVC compiler on a windows/arm64 target.

Steps to reproduce

Visual Studio 2019 or higher is required for compilation.

Compilation can be done natively on a win/arm64 machine or can be cross-compiled from an x86/x64 machine.

From a command terminal

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsx86_arm64.bat

cmake -G "NMake Makefiles" -D DOWNLOAD_GTEST=1 -D CMAKE_BUILD_TYPE=Debug .

nmake test_xsimd

The issue has been noticed while building the apache arrow library and would be required to build an apache arrow for win/arm64 using MSVC.

@niyas-sait
Copy link
Author

The main issue seems to be due to MSVC arm/neon intrinsic vector type using the same underlying type for the neon vectors.

e.g: int8x16_t and uint8x16_t maps to __n128 type

This causes a couple of issues

  • Function overloading issues as functions with same functions redefined in xsimd
  • Neon dispatcher doesn't pick the right function as all of the functions might be using the same underlying type.

And other issues are

  • reinterpret_cast doesn't work on neon vector types
  • intrinsic functions defined using macro which might overwrite functions with the same name even defined under a namespace (e.g: wrap::vadd_f32)
  • NEON identification require different flag checks
  • Initializer_list constructor missing for neon vector types

@niyas-sait
Copy link
Author

Few approaches I can think of

  • A) Replace the dispatcher to not use target vector type and use the scalar vector type to find the functions to use.
  • B) Define a wrapper class for msvc neon vector types so that they are distinguishable and can be used with the current dispatcher mechanism.

@niyas-sait
Copy link
Author

Pull Request for approach (A)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant