Current cmake files use -march=native unconditionally:
|
unset(FASTPFOR_COMPILER_SUPPORTS_MARCH_NATIVE CACHE) |
|
CHECK_CXX_COMPILER_FLAG(-march=native FASTPFOR_COMPILER_SUPPORTS_MARCH_NATIVE) |
|
if(FASTPFOR_COMPILER_SUPPORTS_MARCH_NATIVE) |
|
target_compile_options(FastPFOR PRIVATE -march=native) |
|
else() |
|
message(STATUS "native target not supported") |
|
endif() |
This breaks for many usecases - e.g. when the library is being distributed as a binary. Moreover, it even breaks the GitHub CI builds because there are two types of x64 runners - Intel and AMD, and the later one does not support AVX instruction set. So if a build cache is being used, the build fails - see maplibre/maplibre-tile-spec#1016
Ideally, it should be possible to have a single binary capable of using the right instruction set at the runtime - i.e. dynamic dispatch. There could be a cmake flag with modes like native|compatible|dynamic -- which would produce either the binary for the current CPU, a binary with maximum compatibility to the older CPUs, or the binary that can autodetect CPU instruction set.
Current cmake files use
-march=nativeunconditionally:FastPFOR/CMakeLists.txt
Lines 90 to 96 in aa1a6c3
This breaks for many usecases - e.g. when the library is being distributed as a binary. Moreover, it even breaks the GitHub CI builds because there are two types of x64 runners - Intel and AMD, and the later one does not support AVX instruction set. So if a build cache is being used, the build fails - see maplibre/maplibre-tile-spec#1016
Ideally, it should be possible to have a single binary capable of using the right instruction set at the runtime - i.e. dynamic dispatch. There could be a cmake flag with modes like
native|compatible|dynamic-- which would produce either the binary for the current CPU, a binary with maximum compatibility to the older CPUs, or the binary that can autodetect CPU instruction set.