Closed filiperinaldi closed 4 years ago
The reason sandybridge
is chosen by default is actually that the default choice of the compiler for x86 CPUs (namely x86-64
) is pretty shitty, because it completely disables any vectorized instructions. Because almost all of the x86 CPUs used today support AVX, we chose to use sandybridge
as a fallback, because it was the first CPU to fully support it. And I would say that this default has payed off. It introduced very few problems and made a lot of code faster by default.
I see that this default is problematic when compiling for different architectures. If you have a proposal for any logic to reliably detect this case, I would be happy to introduce it. CMAKE_CROSSCOMPILING
seems to be available, but I a not sure if that works for ARM as well. And it will for sure not work for ARM-native builds...
I will definitely have a look. Cross compilation does not seem to be a major issue as you can add MRT_ARCH to the toolchain.cmake file as the user knows what the target is.
Arguably not an bug report, but a feature request...
UseMrtStdCompilerFlags.cmake restricts the use of these modules to amd64 machines by defaulting to "sandybridge":
Trying to build a project using mrt_cmake_modules in an AArch64 (Arm) machine fails. The failure can be obvious (you will see compilation errors and with the mach=sandybridge flag being used, or some find_package() may fail with no reason (this is due the fact they use the CMake's try/run mechanism to build small C apps).
Note that this was the real problem why find_package(OpenMP) was failing for me on this issue: #6
Is there a good reason why sandybridge is being forced as the defaul mach? The compiler will already have default to a sane value for the target it is running from. If the "application" using mrt_cmake_modules has a minimum arch target requirement, then I suppose this is what MRT_ARCH is there for.