Thank you for the detailed answer! The introspection sounds also interesting, but at least for the CPU side the arch keyword "native" is already the ideal -march if one compiles directly on the target architecture.
What I was thinking/dreaming of was a workflow close to: (1) a user knows the exact target architecture by name (CPU and GPU) or a system provides CMake templates for it as a module (e.g. per HPC batch system queue). (2) the user (manually/per module) selects a host and device compiler, and cmake looks up the according architecture flag for the compiler. the value of the arch flag comes from the user or a selected system/queue-wide profile. The second step (my initial question) is similar to what CMake already abstracts for -fopenmp and -fPIC flags per compiler. Instead of -fPIC as set(CMAKE_POSITION_INDEPENDENT_CODE ON) I would set set(CMAKE_CXX_ARCH "core-avx2") set(CMAKE_CUDA_ARCH "30;50;60") or directly as property on the target set_property(TARGET libcpp PROPERTIES LINKER_LANGUAGE CXX) set_property(TARGET lib2cu PROPERTIES LINKER_LANGUAGE CUDA) set_property(TARGET libcpp PROPERTY ARCH "core-avx2") set_property(TARGET lib2cu PROPERTY HOST_ARCH "core-avx2") set_property(TARGET lib2cu PROPERTY DEVICE_ARCH "30;50;60") Of course CUDA is weird again since a target can only have one language but a CUDA target has a host *and* a device architecture... Probably per-queue/system compiler wrappers instead of (1) would serve the same purpose... Anyway, I was just wondering if that is already somehow covered in cross-compiling support (1) or compiler flag abstractions (2). Thanks again and sorry for verbose mumbling! On 06.10.2017 15:07, Robert Maynard wrote: > CMAKE_SYSTEM_PROCESSOR is a read-only variable that CMake will > populate to help inform projects what kind of platform they are > running on X86_64/ARM/PowerPC. It will not provide the level of detail > information needed to determine what specific architecture you should > specify. The best place to add such information would be the > cmake_host_system_information() call which already supports a limited > ability to query the host system. The underlying infrastructure does > support asking about the actual CPU architecture it just never has > been exposed. > > So in summary there is no best practice on how to specify the best > matching architecture flags, and currently it has been left up to each > project > > For CUDA the FindCUDA module does have select_compute_arch.cmake which > does system introspection to determine the set of CUDA flags. This can > be can be used with the new native CUDA support by passing the results > to CMAKE_CUDA_FLAGS or with target_compile_options and > $<COMPILE_LANGUAGE:CUDA>. > > On Fri, Oct 6, 2017 at 5:42 AM, Axel Huebl <a.hu...@hzdr.de> wrote: >> Dear CMake List, >> >> >> we are building HPC software with CMake. In many cases, we find that the >> performance of (auto)vectorization heavy code depends greatly on >> specifying the exact processor generation for optimally tuned binaries. >> That is no surprise, since a compiler's architecture flags just group an >> according set of available instructions for e.g. SIMD extensions. >> >> The question now is: Is there a generic CMake best-practice to specify >> the *exact* architecture -mtune/-march/-mcpu/-qarch/-x/... flags, >> ideally according to the currently used compiler (icc,gcc,xlc,pgc,...) >> just from the name of the processor generation? >> >> CMAKE_SYSTEM_PROCESSOR looks like it but its documentation is a bit >> short. Does it allow me to set details such as "bdver1", "corei7-avx" or >> "core-avx2" as targets (instead of generic "x86_64")? >> >> Note: Portability of binaries is not relevant since we can re-compile >> for each system (and have performance portable source code). >> >> Vice versa, is there a way already for setting the CUDA compute >> capabilities of a target via a CMake variable? >> >> For both cases, we currently hijack CXX flags and do switches on >> compilers, which is probably not the most generic way to write >> maintainable CMake scripts. For NVCC and Clang CUDA SM targets for PTX >> and SASS code embedding, we just have our own CMake variable, which is >> also sub-ideal for as it is not standardized. >> >> How do you usually address this? >> >> >> All the best, >> Axel >> -- >> >> Axel Huebl >> Phone +49 351 260 3582 >> https://www.hzdr.de/crp >> Computational Radiation Physics >> Laser Particle Acceleration Division >> Helmholtz-Zentrum Dresden - Rossendorf e.V. >> >> Bautzner Landstrasse 400, 01328 Dresden >> POB 510119, D-01314 Dresden >> Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey >> Prof. Dr.Dr.h.c. P. Joehnk >> VR 1693 beim Amtsgericht Dresden >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake-developers > -- Axel Huebl Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers