[Openmp-dev] AArch64 support

[Peyton, Jonathan L]

-if(NOT arch)
-   if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "4")
-       set(arch           32          CACHE STRING "The architecture to build for (32e/32/arm/ppc64).  32e is Intel(R) 64 architecture, 32 is IA-32 architecture")
-   else()
-       set(arch           32e         CACHE STRING "The architecture to build for (32e/32/arm/ppc64).  32e is Intel(R) 64 architecture, 32 is IA-32 architecture")
-   endif()
+#if(NOT arch)
+#  if("${CMAKE_SIZEOF_VOID_P}" STREQUAL "4")
+#      set(arch           32          CACHE STRING "The architecture to build for (32e/32/arm/ppc64/aarch64).  32e is Intel(R) 64 architecture, 32 is IA-32 architecture")
+#  else()
+#      set(arch           32e         CACHE STRING "The architecture to build for (32e/32/arm/ppc64/aarch64).  32e is Intel(R) 64 architecture, 32 is IA-32 architecture")
+#  endif()
+#endif()

We can get rid of the if(NOT arch) line, this guard is unnecessary.

When CMake is first run on a build directory, it creates a CMakeCache.txt file inside the build directory which is the configuration of your build.  Any variable in the CMakeLists.txt file which is set with the CACHE option (along with a type and docstring) is either set from the command line via –DVARIABLE=value or from this default value in the CMakeLists.txt file.  The –DVARIABLE=value takes precedence over what is in the CMakeLists.txt file in the initial CMake run.  On subsequent runs of CMake, VARIABLE is set *FROM THE CMakeCache.txt* file.  You can change this value in CMakeCache.txt manually or with:
cmake –DVARIABLE=value ..
In summary, the first run of CMake sets the initial value of arch either with –Darch=value, or by the logic in the CMakeLists.txt file.  After that initial run, it grabs the value of arch from CMakeCache.txt.  An example might help illustrate what I’m saying:

[ This assumes you don’t blast away the build directory between cmake runs ]
1) cmake –Darch=arm (Rest of your variables) ..   [ This will override what is in CMakeLists.txt and put arm in CMakeCache.txt and set arch to arm for the initial CMake run)
…
2) cmake –Dsome_other_variable=value .. [ This will use the arch value stored in CMakeCache.txt (currently arm) ]
…
3) cmake –Darch=32e .. [ This will set the value in CMakeCache.txt to 32e and use 32e during this third run of CMake ]
…
4) vi CMakeCache.txt (edit arch to be ppc64)
5) make (This call to GNU Make will recall cmake but use value of arch in CMakeCache.txt which is ppc64)

-- Johnny

From: openmp-dev-bounces at cs.uiuc.edu [mailto:openmp-dev-bounces at cs.uiuc.edu] On Behalf Of Cownie, James H
Sent: Monday, October 27, 2014 7:01 AM
To: C Bergström; openmp-dev at dcs-maillist2.engr.illinois.edu
Subject: Re: [Openmp-dev] AArch64 support

+if("${arch}" STREQUAL "32e" OR "${arch}" STREQUAL "32" OR "${arch}" STREQUAL "arm" OR "${arch}" STREQUAL "aarch64")
     set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_USE_ADAPTIVE_LOCKS=1")
     set(FEATURE_FLAGS "${FEATURE_FLAGS} -D KMP_DEBUG_ADAPTIVE_LOCKS=0")
endif()

Do you really want the adaptive locks for arm and aarch64?
Since they use the Intel specific transactional synchronization extensions (TSX) it seems unlikely to me.

Otherwise LGTM (though I have no testing environment for it).

-- Jim

James Cownie <james.h.cownie at intel.com<mailto:james.h.cownie at intel.com>>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438

From: openmp-dev-bounces at cs.uiuc.edu<mailto:openmp-dev-bounces at cs.uiuc.edu> [mailto:openmp-dev-bounces at cs.uiuc.edu] On Behalf Of C Bergström
Sent: Sunday, October 26, 2014 7:05 PM
To: openmp-dev at dcs-maillist2.engr.illinois.edu<mailto:openmp-dev at dcs-maillist2.engr.illinois.edu>
Subject: Re: [Openmp-dev] AArch64 support



On Sun, Oct 26, 2014 at 8:34 PM, C Bergström <cbergstrom at pathscale.com<mailto:cbergstrom at pathscale.com>> wrote:
Hi

Does anyone have a patch for AArch64 support? Either experimental, complete or notes/suggestions.

So here's a 1st draft for review - I don't expect it to be clean on the 1st pass, but getting some review would be really appreciated.

btw - Is anyone testing this on ARM or PPC64 regularly?

Thanks



---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20141027/d9f141bf/attachment.html>