[cmake-developers] CMake Var for Specific Processor Type

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

-- 

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


More information about the cmake-developers mailing list