llvm-project/openmp/libomptarget
Alexey Bataev ca424d100c [OPENMP][NVPTX]Perform memory flush if number of threads to sync is 1 or less.
Summary:
According to the OpenMP standard, barrier operation must perform
implicit flush operation. Currently, if there is only one thread in the
team, barrier does not flush the memory. Patch fixes this problem.

Reviewers: grokos, gtbercea, kkwli0

Subscribers: guansong, jdoerfert, openmp-commits, caomhin

Tags: #openmp

Differential Revision: https://reviews.llvm.org/D62398

llvm-svn: 367024
2019-07-25 15:02:28 +00:00
..
cmake/Modules [OpenMP][libomptarget] Suppress C++ 11 related warnings when building libomptarget-nvptx bitcode library, by Doru Bercea. 2019-07-18 13:54:01 +00:00
deviceRTLs [OPENMP][NVPTX]Perform memory flush if number of threads to sync is 1 or less. 2019-07-25 15:02:28 +00:00
include [OpenMP][libomptarget] Enable usage of unified memory for declare target link variables 2019-06-04 15:05:53 +00:00
plugins [OpenMP][libomptarget] Add support for declare target to clause under unified memory 2019-06-19 15:48:10 +00:00
src [libomptarget] Handle offload policy in push_tripcount 2019-07-23 14:20:48 +00:00
test [OPENMP] Resolve lost LoopTripCnt for subsequent loops in same thread. 2019-07-17 17:07:52 +00:00
CMakeLists.txt [libomptarget] Introduce LIBOMPTARGET_ENABLE_DEBUG cmake option. 2019-03-26 15:19:15 +00:00
README.txt Unify build documentation and convert to reStructuredText 2017-12-27 09:15:10 +00:00

README.txt

    README for the LLVM* OpenMP* Offloading Runtime Library (libomptarget)
    ======================================================================

How to Build the LLVM* OpenMP* Offloading Runtime Library (libomptarget)
========================================================================
In-tree build:

$ cd where-you-want-to-live
Check out openmp (libomptarget lives under ./libomptarget) into llvm/projects
$ cd where-you-want-to-build
$ mkdir build && cd build
$ cmake path/to/llvm -DCMAKE_C_COMPILER=<C compiler> -DCMAKE_CXX_COMPILER=<C++ compiler>
$ make omptarget

Out-of-tree build:

$ cd where-you-want-to-live
Check out openmp (libomptarget lives under ./libomptarget)
$ cd where-you-want-to-live/openmp/libomptarget
$ mkdir build && cd build
$ cmake path/to/openmp -DCMAKE_C_COMPILER=<C compiler> -DCMAKE_CXX_COMPILER=<C++ compiler>
$ make

For details about building, please look at README.rst in the parent directory.

Architectures Supported
=======================
The current library has been only tested in Linux operating system and the
following host architectures:
* Intel(R) 64 architecture
* IBM(R) Power architecture (big endian)
* IBM(R) Power architecture (little endian)
* ARM(R) AArch64 architecture (little endian)

The currently supported offloading device architectures are:
* Intel(R) 64 architecture (generic 64-bit plugin - mostly for testing purposes)
* IBM(R) Power architecture (big endian) (generic 64-bit plugin - mostly for testing purposes)
* IBM(R) Power architecture (little endian) (generic 64-bit plugin - mostly for testing purposes)
* ARM(R) AArch64 architecture (little endian) (generic 64-bit plugin - mostly for testing purposes)
* CUDA(R) enabled 64-bit NVIDIA(R) GPU architectures

Supported RTL Build Configurations
==================================
Supported Architectures: Intel(R) 64, IBM(R) Power 7 and Power 8

              ---------------------------
              |   gcc      |   clang    |
--------------|------------|------------|
| Linux* OS   |  Yes(1)    |  Yes(2)    |
-----------------------------------------

(1) gcc version 4.8.2 or later is supported.
(2) clang version 3.7 or later is supported.


Front-end Compilers that work with this RTL
===========================================

The following compilers are known to do compatible code generation for
this RTL:
  - clang (from https://github.com/clang-ykt )
  - clang (development branch at http://clang.llvm.org - several features still
    under development)

-----------------------------------------------------------------------

Notices
=======
This library and related compiler support is still under development, so the
employed interface is likely to change in the future.

*Other names and brands may be claimed as the property of others.