[cmake-developers] CMake Var for Specific Processor Type

[Robert Maynard]

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.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
> --
>
> 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