2013-09-27 18:38:44 +08:00
|
|
|
|
2015-05-12 20:52:43 +08:00
|
|
|
README for the LLVM* OpenMP* Runtime Library
|
|
|
|
|
============================================
|
2013-09-27 18:38:44 +08:00
|
|
|
|
|
|
|
|
How to Build Documentation
|
|
|
|
|
==========================
|
|
|
|
|
|
|
|
|
|
The main documentation is in Doxygen* format, and this distribution
|
|
|
|
|
should come with pre-built PDF documentation in doc/Reference.pdf.
|
|
|
|
|
However, an HTML version can be built by executing:
|
|
|
|
|
|
|
|
|
|
% doxygen doc/doxygen/config
|
|
|
|
|
|
2015-05-12 20:52:43 +08:00
|
|
|
in the runtime directory.
|
2013-09-27 18:38:44 +08:00
|
|
|
|
|
|
|
|
That will produce HTML documentation in the doc/doxygen/generated
|
|
|
|
|
directory, which can be accessed by pointing a web browser at the
|
|
|
|
|
index.html file there.
|
|
|
|
|
|
|
|
|
|
If you don't have Doxygen installed, you can download it from
|
|
|
|
|
www.doxygen.org.
|
|
|
|
|
|
|
|
|
|
|
2015-05-12 20:52:43 +08:00
|
|
|
How to Build the LLVM* OpenMP* Runtime Library
|
|
|
|
|
==============================================
|
2013-09-27 18:38:44 +08:00
|
|
|
|
2015-05-12 20:52:43 +08:00
|
|
|
The library can be built either using Cmake, or using a makefile that
|
|
|
|
|
in turn invokes various Perl scripts. For porting, non X86
|
|
|
|
|
architectures, and for those already familiar with Cmake that may be
|
|
|
|
|
an easier route to take than the one described here.
|
|
|
|
|
|
|
|
|
|
Building with CMake
|
|
|
|
|
===================
|
|
|
|
|
The runtime/Build_With_CMake.txt file has a description of how to
|
|
|
|
|
build with Cmake.
|
|
|
|
|
|
|
|
|
|
Building with the Makefile
|
|
|
|
|
==========================
|
2013-09-27 18:38:44 +08:00
|
|
|
The Makefile at the top-level will attempt to detect what it needs to
|
2015-05-12 20:52:43 +08:00
|
|
|
build the LLVM* OpenMP* Runtime Library. To see the default settings,
|
2013-09-27 18:38:44 +08:00
|
|
|
type:
|
|
|
|
|
|
|
|
|
|
make info
|
|
|
|
|
|
|
|
|
|
You can change the Makefile's behavior with the following options:
|
|
|
|
|
|
|
|
|
|
omp_root: The path to the top-level directory containing the top-level
|
|
|
|
|
Makefile. By default, this will take on the value of the
|
|
|
|
|
current working directory.
|
|
|
|
|
|
|
|
|
|
omp_os: Operating system. By default, the build will attempt to
|
2015-05-12 20:52:43 +08:00
|
|
|
detect this. Currently supports "linux", "freebsd", "macos", and
|
2013-09-27 18:38:44 +08:00
|
|
|
"windows".
|
|
|
|
|
|
|
|
|
|
arch: Architecture. By default, the build will attempt to
|
|
|
|
|
detect this if not specified by the user. Currently
|
|
|
|
|
supported values are
|
|
|
|
|
"32" for IA-32 architecture
|
|
|
|
|
"32e" for Intel(R) 64 architecture
|
|
|
|
|
"mic" for Intel(R) Many Integrated Core Architecture
|
2015-05-12 20:52:43 +08:00
|
|
|
"arm" for ARM* architecture
|
|
|
|
|
"aarch64" for Aarch64 (64-bit ARM) architecture
|
2015-01-20 02:29:35 +08:00
|
|
|
"ppc64" for IBM(R) Power architecture (big endian)
|
|
|
|
|
"ppc64le" for IBM(R) Power architecture (little endian)
|
2013-09-27 18:38:44 +08:00
|
|
|
|
|
|
|
|
If "mic" is specified then "icc" will be used as the
|
|
|
|
|
compiler, and appropriate k1om binutils will be used. The
|
|
|
|
|
necessary packages must be installed on the build machine
|
|
|
|
|
for this to be possible (but an Intel(R) Xeon Phi(TM)
|
|
|
|
|
coprocessor card is not required to build the library).
|
|
|
|
|
|
|
|
|
|
compiler: Which compiler to use for the build. Defaults to "icc"
|
|
|
|
|
or "icl" depending on the value of omp_os. Also supports
|
|
|
|
|
some versions of "gcc"* when omp_os is "linux". The selected
|
|
|
|
|
compiler should be installed and in the user's path. The
|
|
|
|
|
corresponding Fortran compiler should also be in the path.
|
|
|
|
|
See "Supported RTL Build Configurations" below for more
|
|
|
|
|
information on compiler versions.
|
|
|
|
|
|
|
|
|
|
mode: Library mode: default is "release". Also supports "debug".
|
|
|
|
|
|
2015-01-29 23:37:15 +08:00
|
|
|
jobs: The number of parallel jobs for the underlying call to make.
|
|
|
|
|
This value is sent as the parameter to the -j flag for make.
|
|
|
|
|
This value defaults to "1", but can be set to any positive integer.
|
|
|
|
|
|
2013-09-27 18:38:44 +08:00
|
|
|
To use any of the options above, simple add <option_name>=<value>. For
|
|
|
|
|
example, if you want to build with gcc instead of icc, type:
|
|
|
|
|
|
|
|
|
|
make compiler=gcc
|
|
|
|
|
|
I apologise in advance for the size of this check-in. At Intel we do
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
2014-10-08 00:25:50 +08:00
|
|
|
On OS X* machines, it is possible to build universal (or fat) libraries which
|
|
|
|
|
include both IA-32 architecture and Intel(R) 64 architecture objects in a
|
|
|
|
|
single archive; just build the 32 and 32e libraries separately, then invoke
|
|
|
|
|
make again with a special argument as follows:
|
|
|
|
|
|
|
|
|
|
make compiler=clang build_args=fat
|
|
|
|
|
|
2013-09-27 18:38:44 +08:00
|
|
|
Supported RTL Build Configurations
|
|
|
|
|
==================================
|
|
|
|
|
|
|
|
|
|
Supported Architectures: IA-32 architecture, Intel(R) 64, and
|
|
|
|
|
Intel(R) Many Integrated Core Architecture
|
|
|
|
|
|
I apologise in advance for the size of this check-in. At Intel we do
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
2014-10-08 00:25:50 +08:00
|
|
|
----------------------------------------------
|
|
|
|
|
| icc/icl | gcc | clang |
|
|
|
|
|
--------------|---------------|----------------------------|
|
|
|
|
|
| Linux* OS | Yes(1,5) | Yes(2,4) | Yes(4,6,7) |
|
|
|
|
|
| FreeBSD* | No | No | Yes(4,6,7,8) |
|
|
|
|
|
| OS X* | Yes(1,3,4) | No | Yes(4,6,7) |
|
|
|
|
|
| Windows* OS | Yes(1,4) | No | No |
|
|
|
|
|
------------------------------------------------------------
|
2013-09-27 18:38:44 +08:00
|
|
|
|
|
|
|
|
(1) On IA-32 architecture and Intel(R) 64, icc/icl versions 12.x are
|
|
|
|
|
supported (12.1 is recommended).
|
I apologise in advance for the size of this check-in. At Intel we do
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
2014-10-08 00:25:50 +08:00
|
|
|
(2) GCC* version 4.6.2 is supported.
|
2013-09-27 18:38:44 +08:00
|
|
|
(3) For icc on OS X*, OS X* version 10.5.8 is supported.
|
|
|
|
|
(4) Intel(R) Many Integrated Core Architecture not supported.
|
|
|
|
|
(5) On Intel(R) Many Integrated Core Architecture, icc/icl versions 13.0
|
|
|
|
|
or later are required.
|
I apologise in advance for the size of this check-in. At Intel we do
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
2014-10-08 00:25:50 +08:00
|
|
|
(6) Clang* version 3.3 is supported.
|
|
|
|
|
(7) Clang* currently does not offer a software-implemented 128 bit extended
|
2013-12-24 01:28:57 +08:00
|
|
|
precision type. Thus, all entry points reliant on this type are removed
|
|
|
|
|
from the library and cannot be called in the user program. The following
|
|
|
|
|
functions are not available:
|
|
|
|
|
__kmpc_atomic_cmplx16_*
|
|
|
|
|
__kmpc_atomic_float16_*
|
|
|
|
|
__kmpc_atomic_*_fp
|
I apologise in advance for the size of this check-in. At Intel we do
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
2014-10-08 00:25:50 +08:00
|
|
|
(8) Community contribution provided AS IS, not tested by Intel.
|
2013-09-27 18:38:44 +08:00
|
|
|
|
2015-08-28 01:19:17 +08:00
|
|
|
Supported Architectures: IBM(R) Power 7 and Power 8
|
|
|
|
|
|
|
|
|
|
-----------------------------
|
|
|
|
|
| gcc | clang |
|
|
|
|
|
--------------|------------|--------------|
|
|
|
|
|
| Linux* OS | Yes(1,2) | Yes(3,4) |
|
|
|
|
|
-------------------------------------------
|
|
|
|
|
|
|
|
|
|
(1) On Power 7, gcc version 4.8.2 is supported.
|
|
|
|
|
(2) On Power 8, gcc version 4.8.2 is supported.
|
|
|
|
|
(3) On Power 7, clang version 3.7 is supported.
|
|
|
|
|
(4) On Power 8, clang version 3.7 is supported.
|
|
|
|
|
|
|
|
|
|
|
2013-09-27 18:38:44 +08:00
|
|
|
Front-end Compilers that work with this RTL
|
|
|
|
|
===========================================
|
|
|
|
|
|
|
|
|
|
The following compilers are known to do compatible code generation for
|
2015-05-12 20:52:43 +08:00
|
|
|
this RTL: clang (from the OpenMP development branch at
|
|
|
|
|
http://clang-omp.github.io/ ), Intel compilers, GCC. See the documentation
|
|
|
|
|
for more details.
|
2013-09-27 18:38:44 +08:00
|
|
|
|
|
|
|
|
-----------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
Notices
|
|
|
|
|
=======
|
|
|
|
|
|
|
|
|
|
*Other names and brands may be claimed as the property of others.
|