summaryrefslogtreecommitdiffstats
path: root/openmp/runtime/cmake/BuildPLRules.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Large Refactor of CMake build systemJonathan Peyton2015-07-151-112/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit improves numerous functionalities of the OpenMP CMake build system to be more conducive with LLVM's build system and build philosophies. The CMake build system, as it was before this commit, was not up to LLVM's standards and did not implement the configuration stage like most CMake based build systems offer (check for compiler flags, libraries, etc.) In order to improve it dramatically in a short period of time, a large refactoring had to be done. The main changes done with this commit are as follows: * Compiler flag checks - The flags are no longer grabbed from compiler specific directories. They are checked for availability in config-ix.cmake and added accordingly inside LibompHandleFlags.cmake. * Feature checks were added in config-ix.cmake. For example, the standard CMake module FindThreads is probed for the threading model to use inside the OpenMP library. * OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning a Unix flavor of some sort. * Got rid of vestigial functions/macros/variables * Added new libomp_append() function which is used everywhere to conditionally or undconditionally append to a list * All targets have the libomp prefix so as not to interfere with any other project * LibompCheckLinkerFlag.cmake module was added which checks for linker flags specifically for building shared libraries. * LibompCheckFortranFlag.cmake module was added which checks for fortran flag availability. * Removed most of the cruft from the translation between the perl+Makefile based build system and this one. The remaining components that they share are perl scripts which I'm in the process of removing. There is still more left to do. The perl scripts still need to be removed, and a config.h.in file (or similarly named) needs to be added with #cmakedefine lines in it. But this is a much better first step than the previous system. Differential Revision: http://reviews.llvm.org/D10656 llvm-svn: 242298
* Apply name change to CMake build system.Jonathan Peyton2015-06-011-13/+13
| | | | | | | | | | | This change has the CMake build system create a dynamic library named libomp instead of libiomp5. Also any reference to libiomp is replaced with libomp. One can still use the LIBOMP_LIB_NAME variable to enforce a different name, and everything will still work as expected. An important note is that libiomp5 and libgomp symlinks are created at install time when on Unix systems. On Windows, copies are created with the legacy names. llvm-svn: 238715
* Change CMake variable prefix to LIBOMPJonathan Peyton2015-05-201-1/+1
| | | | | | | | | | | Cached CMake variables need to have a prefix so they don't collide with other projects. This change (a lot of simple changes) simply prefixes cached variables with LIBOMP_ and sets all of these variables to UPPERCASE which is convention. e.g., os => LIBOMP_OS, ompt_support => LIBOMP_OMPT_SUPPORT. Differential Revision: http://reviews.llvm.org/D9829 llvm-svn: 237845
* cleanup changes of cmake-building for Intel(R) Many Integrated Core ArchitectureAndrey Churbanov2015-01-161-1/+2
| | | | llvm-svn: 226272
* I apologise in advance for the size of this check-in. At Intel we doJim Cownie2014-10-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | understand that this is not friendly, and are working to change our internal code-development to make it easier to make development features available more frequently and in finer (more functional) chunks. Unfortunately we haven't got that in place yet, and unpicking this into multiple separate check-ins would be non-trivial, so please bear with me on this one. We should be better in the future. Apologies over, what do we have here? GGC 4.9 compatibility -------------------- * We have implemented the new entrypoints used by code compiled by GCC 4.9 to implement the same functionality in gcc 4.8. Therefore code compiled with gcc 4.9 that used to work will continue to do so. However, there are some other new entrypoints (associated with task cancellation) which are not implemented. Therefore user code compiled by gcc 4.9 that uses these new features will not link against the LLVM runtime. (It remains unclear how to handle those entrypoints, since the GCC interface has potentially unpleasant performance implications for join barriers even when cancellation is not used) --- new parallel entry points --- new entry points that aren't OpenMP 4.0 related These are implemented fully :- GOMP_parallel_loop_dynamic() GOMP_parallel_loop_guided() GOMP_parallel_loop_runtime() GOMP_parallel_loop_static() GOMP_parallel_sections() GOMP_parallel() --- cancellation entry points --- Currently, these only give a runtime error if OMP_CANCELLATION is true because our plain barriers don't check for cancellation while waiting GOMP_barrier_cancel() GOMP_cancel() GOMP_cancellation_point() GOMP_loop_end_cancel() GOMP_sections_end_cancel() --- taskgroup entry points --- These are implemented fully. GOMP_taskgroup_start() GOMP_taskgroup_end() --- target entry points --- These are empty (as they are in libgomp) GOMP_target() GOMP_target_data() GOMP_target_end_data() GOMP_target_update() GOMP_teams() Improvements in Barriers and Fork/Join -------------------------------------- * Barrier and fork/join code is now in its own file (which makes it easier to understand and modify). * Wait/release code is now templated and in its own file; suspend/resume code is also templated * There's a new, hierarchical, barrier, which exploits the cache-hierarchy of the Intel(r) Xeon Phi(tm) coprocessor to improve fork/join and barrier performance. ***BEWARE*** the new source files have *not* been added to the legacy Cmake build system. If you want to use that fixes wil be required. Statistics Collection Code -------------------------- * New code has been added to collect application statistics (if this is enabled at library compile time; by default it is not). The statistics code itself is generally useful, the lightweight timing code uses the X86 rdtsc instruction, so will require changes for other architectures. The intent of this code is not for users to tune their codes but rather 1) For timing code-paths inside the runtime 2) For gathering general properties of OpenMP codes to focus attention on which OpenMP features are most used. Nested Hot Teams ---------------- * The runtime now maintains more state to reduce the overhead of creating and destroying inner parallel teams. This improves the performance of code that repeatedly uses nested parallelism with the same resource allocation. Set the new KMP_HOT_TEAMS_MAX_LEVEL envirable to a depth to enable this (and, of course, OMP_NESTED=true to enable nested parallelism at all). Improved Intel(r) VTune(Tm) Amplifier support --------------------------------------------- * The runtime provides additional information to Vtune via the itt_notify interface to allow it to display better OpenMP specific analyses of load-imbalance. Support for OpenMP Composite Statements --------------------------------------- * Implement new entrypoints required by some of the OpenMP 4.1 composite statements. Improved ifdefs --------------- * More separation of concepts ("Does this platform do X?") from platforms ("Are we compiling for platform Y?"), which should simplify future porting. ScaleMP* contribution --------------------- Stack padding to improve the performance in their environment where cross-node coherency is managed at the page level. Redesign of wait and release code --------------------------------- The code is simplified and performance improved. Bug Fixes --------- *Fixes for Windows multiple processor groups. *Fix Fortran module build on Linux: offload attribute added. *Fix entry names for distribute-parallel-loop construct to be consistent with the compiler codegen. *Fix an inconsistent error message for KMP_PLACE_THREADS environment variable. llvm-svn: 219214
* After three iterations of community review, we believe that this newJim Cownie2014-08-051-0/+100
CMAKE buld system should meet everyone's requirements. Enhanced CMake Build System Commit * Supports Linux, Mac, Windows, and IntelĀ® Xeon Phi builds * Supports building with gcc, icc, clang, and Visual Studio compilers * Supports bulding "fat" libraries on OS/X with clang * Details and documentation on how to use build system are in Build_With_CMake.txt * To use the old CMake build system (corresponds to CMakeLists.txt.old), just rename CMakeLists.txt to CMakeLists.txt.other and rename CMakeLists.txt.old to CMakeLists.txt llvm-svn: 214850
OpenPOWER on IntegriCloud