[Openmp-dev] PPC64 patch from Intel's fourth cmake patch

Peyton, Jonathan L jonathan.l.peyton at intel.com
Thu Aug 7 14:46:36 PDT 2014


>Others appear to have solved this though https://github.com/petroules/solar-cmake/blob/master/TargetArch.cmake
>
>Seems to cleanly wrap the if() statements and provide a reliable way to detect what's needed. I do slightly question if it will be perfect for PPC64, but I guess it wouldn't be too hard to patch.

I think it is a stretch to call this clean.  It is slick, but it relies on predefined compiler macros to detect the architecture on non-macosx operating systems. 
It creates a dummy C file with all the #if __ARCH_MACRO__, "compiles and runs" it, then takes the stderr
from the compiler output as the architecture.

>llvm/clang may have something similar as well..
LLVM uses uname indirectly.  I have dug through this a little, the calling sequence goes as follows for cmake:
Top Level CMakeLists.txt --> (includes) cmake/config-ix.cmake --> (includes) cmake/GetHostTriple.cmake --> (calls) get_host_triple() --> (calls) sh autoconf/config.guess --> (calls) uname
The variable at interest is LLVM_NATIVE_ARCH.  It appears someone has already done the if() work (in autoconf/config.guess) for autoconf and LLVM uses that for non-Windows machines.

-- Johnny

-----Original Message-----
From: "C. Bergström" [mailto:cbergstrom at pathscale.com] 
Sent: Wednesday, August 6, 2014 9:05 PM
To: Peyton, Jonathan L
Cc: Carlo Bertolli; openmp-dev at dcs-maillist2.engr.illinois.edu; Michael Wong; Cownie, James H
Subject: Re: [Openmp-dev] PPC64 patch from Intel's fourth cmake patch

On 08/ 7/14 06:07 AM, Peyton, Jonathan L wrote:
> C. Bergström, Carlo,
>
>>> ---------
>>> using uname to detect the host/target was rejected before. Please 
>>> use the "cmake" way of detecting things.
>>> +EXECUTE_PROCESS( COMMAND uname -m COMMAND tr -d '\n' 
>>> +OUTPUT_VARIABLE
>>> DETECT_ARCH )
>>> +EXECUTE_PROCESS( COMMAND uname -m COMMAND tr -d '\n' 
>>> +OUTPUT_VARIABLE ARCH )
>>>
>> OK. I did some investigation on this and have done it again just now but was not able to find a way of doing this natively in cmake.
>> Actually, I found comments about how cmake does not support this natively (may be an old cmake version).
>> Can you suggest how to do this? (a link to a web page with an example is fine too).
> I have done some research on this topic.  You are both right :) .  
> There is a cmakey way to get at uname output, and this particular variable is CMAKE_HOST_SYSTEM_PROCESSOR which Is defined by uname -p (slightly different but seems to be preferred over uname -m for reasons I'm not sure).  You can actually see this in the standard cmake modules located at:
> /path/to/cmake_install_root/share/cmake-2.8/Modules/CMakeDetermineSyst
> em.cmake
>
> The problem with using this as an architecture detection mechanism: it is not standard.  Some systems will define uname -p as x86_64, amd64, x64, etc.  This information is embedded in the kernel, and I was not inclined to try to gather all possible values into a giant if() statement to determine if it was 64 bit x86 architecture (same for 32 bit x86).
>
> So if there is a need to put something like this back in, use the CMAKE_HOST_SYSTEM_PROCESSOR variable because it won't mess up Windows builds that don't even have uname to depend on.
Ok I didn't realize it was still such a pita.

Others appear to have solved this though https://github.com/petroules/solar-cmake/blob/master/TargetArch.cmake

Seems to cleanly wrap the if() statements and provide a reliable way to detect what's needed. I do slightly question if it will be perfect for PPC64, but I guess it wouldn't be too hard to patch.

If this isn't sufficient I can keep looking or maybe give a hand fixing it.

llvm/clang may have something similar as well..





More information about the Openmp-dev mailing list