[cmake-developers] CMake Var for Specific Processor Type
a.huebl at hzdr.de
Fri Oct 6 10:44:37 EDT 2017
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
(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
The second step (my initial question) is similar to what CMake already
abstracts for -fopenmp and -fPIC flags per compiler.
Instead of -fPIC as
I would set
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
> 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
> On Fri, Oct 6, 2017 at 5:42 AM, Axel Huebl <a.huebl at 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 Huebl
>> Phone +49 351 260 3582
>> 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:
Phone +49 351 260 3582
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
More information about the cmake-developers