On most platforms, certain compiler and linker flags have to be passed
when using pthreads, otherwise linking against libomp.so might fail with
undefined references to several pthread functions.
Use CMake's `find_package(Threads)` to determine these for standalone
builds, or take them (and optionally modify them) from the top-level
LLVM cmake files.
Also, On FreeBSD, ensure that libomp.so is linked against libm.so,
similar to NetBSD.
Adjust test cases with hardcoded `-lpthread` flag to use the common
build flags, which should now have the required pthread flags.
Reviewers: emaste, jlpeyton, krytarowski, mgorny, protze.joachim, Hahnfeld
Reviewed By: Hahnfeld
Subscribers: AndreyChurbanov, tra, EricWF, Hahnfeld, jfb, jdoerfert, openmp-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D59451
llvm-svn: 357618
The thread-limit-var and omp_get_thread_limit API was not perfectly handled for
teams construct. Now, when modified by thread_limit clause, omp_get_thread_limit
reports the correct value. In addition, the value is restored when leaving the
teams construct to what it was in the encountering context.
This is done partly by creating the notion of a Contention Group root (CG root)
that keeps track of the thread at the root of each separate CG, the
thread-limit-var associated with the CG, and associated counter of active
threads within the contention group.
thread-limits are passed from master to worker threads via an entry in the ICV
data structure. When a "contention group switch" occurs, a new CG root record is
made and passed from master to worker. A thread could potentially have several
CG root records if it encounters multiple nested teams constructs (but at the
moment the spec doesn't allow for nested teams, so the most one could have
currently is 2). The master of the teams masters gets the thread-limit clause
value stored to its local ICV structure, and the other teams masters copy it
from the master. The thread-limit is set from that ICV copy and restored to the
ICV copy when entering and leaving the teams construct.
This change also fixes a bug when the top-level teams construct team gets
reused, and OMP_DYNAMIC was true, which can cause the expected size of this team
to be smaller than what was actually allocated. The fix updates the size of the
team after its threads were reserved.
Patch by Terry Wilmarth
Differential Revision: https://reviews.llvm.org/D56804
llvm-svn: 353747
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
The omp-tools.h file is generated from the OpenMP spec to ensure that the interface
is implemented as specified.
The other changes are necessary to update the interface implementation to the
final version as published in 5.0.
The omp-tools.h header was previously called ompt.h, currently a copy under this name
is installed for legacy tools.
Patch partially perpared by @sconvent
Reviewers: AndreyChurbanov, hbae, Hahnfeld
Reviewed By: hbae
Tags: #openmp, #ompt
Differential Revision: https://reviews.llvm.org/D55579
llvm-svn: 351197
Summary:
Additions mostly follow FreeBSD and NetBSD and are not intrusive.
There is similar patch for OpenBSD: https://reviews.llvm.org/D34280
The -lm was being omitted due to -Wl,--as-needed in cmake rule, similar patch is in freebsd-ports/devel/llvm-devel port.
Simple OpenMP programs compile and work as expected:
$ clang-devel ~/omp_hello.c -fopenmp -I/usr/local/llvm-devel/include
$ LD_LIBRARY_PATH=/usr/local/llvm-devel/lib OMP_NUM_THREADS=100 ./a.out
The assertion in LLVMgold.so when -fopenmp was used together with -flto in 20170524 snapshot is no longer triggered on current svn-trunk and works fine as in llvm-4.0 with our local patches.
Reviewers: #openmp, krytarowski
Reviewed By: krytarowski
Subscribers: dexonsmith, jfb, krytarowski, guansong, gregrodgers, emaste, mgorny, mehdi_amini
Differential Revision: https://reviews.llvm.org/D35129
llvm-svn: 348725
This patch cleans up unused functions, variables, sign compare issues, and
addresses some -Warning flags which are now enabled including -Wcast-qual.
Not all the warning flags in LibompHandleFlags.cmake are enabled, but some
are with this patch.
Some __kmp_gtid_from_* macros in kmp.h are switched to static inline functions
which allows us to remove the awkward definition of KMP_DEBUG_ASSERT() and
KMP_ASSERT() macros which used the comma operator. This had to be done for the
innumerable -Wunused-value warnings related to KMP_DEBUG_ASSERT()
Differential Revision: https://reviews.llvm.org/D49105
llvm-svn: 339393
GCC 8 produces false-positives with this:
In file included from <openmp>/src/runtime/src/kmp_os.h:950,
from <openmp>/src/runtime/src/kmp.h:78,
from <openmp>/src/runtime/src/kmp_environment.cpp:54:
<openmp>/src/runtime/src/kmp_environment.cpp: In function ‘char* __kmp_env_get(const char*)’:
<openmp>/src/runtime/src/kmp_safe_c_api.h:52:50: warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
#define KMP_STRNCPY_S(dst, bsz, src, cnt) strncpy(dst, src, cnt)
~~~~~~~^~~~~~~~~~~~~~~
<openmp>/src/runtime/src/kmp_environment.cpp:97:5: note: in expansion of macro ‘KMP_STRNCPY_S’
KMP_STRNCPY_S(result, len, value, len);
^~~~~~~~~~~~~
<openmp>/src/runtime/src/kmp_environment.cpp:92:28: note: length computed here
size_t len = KMP_STRLEN(value) + 1;
This is stupid because result is allocated with KMP_INTERNAL_MALLOC(len),
so the arguments are correct.
Differential Revision: https://reviews.llvm.org/D49904
llvm-svn: 338283
This patch enables OMPT by default if version 50 or later is built and the config says, that OMPT will be supported.
Differential Revision: https://reviews.llvm.org/D41508
llvm-svn: 321675
These are needed by both libraries, so we can do that in a
common namespace and unify configuration parameters.
Also make sure that the user isn't requesting libomptarget
if the library cannot be built on the system. Issue an error
in that case.
Differential Revision: https://reviews.llvm.org/D40081
llvm-svn: 319342
Traditionally, the library had a weak symbol for ompt_start_tool()
that served as fallback and disabled OMPT if called. Tools could
provide their own version and replace the default implementation
to register callbacks and lookup functions. This mechanism has
worked reasonably well on Linux systems where this interface was
initially developed.
On Darwin / Mac OS X the situation is a bit more complicated and
the weak symbol doesn't work out-of-the-box. In my tests, the
library with the tool needed to link against the OpenMP runtime
to make the process work. This would effectively mean that a tool
needed to choose a runtime library whereas one design goal of the
interface was to allow tools that are agnostic of the runtime.
The solution is to use dlsym() with the argument RTLD_DEFAULT so
that static implementations of ompt_start_tool() are found in the
main executable. This works because the linker on Mac OS X includes
all symbols of an executable in the global symbol table by default.
To use the same code path on Linux, the application would need to
be built with -Wl,--export-dynamic. To avoid this restriction, we
continue to use weak symbols on Linux systems as before.
Finally this patch extends the existing test to cover all possible
ways of initializing the tool as described by the standard. It
also fixes ompt_finalize() to not call omp_get_thread_num() when
the library is shut down which resulted in hangs on Darwin.
The changes have been tested on Linux to make sure that it passes
the current tests as well as the newly extended one.
Differential Revision: https://reviews.llvm.org/D39801
llvm-svn: 317980
Add build option LIBOMP_OMP_VERSION=50, 5.0 headers, and add the year/month
associated with OpenMP 5.0 in relevant source locations. Also, remove the
deprecated LIBOMP_OMP_VERSION=41 option.
Patch by Olga Malysheva
Differential Revision: https://reviews.llvm.org/D30450
llvm-svn: 297083
This set of changes enables the affinity interface (Either the preexisting
native operating system or HWLOC) to be dynamically set at runtime
initialization. The point of this change is that we were seeing performance
degradations when using HWLOC. This allows the user to use the old affinity
mechanisms which on large machines (>64 cores) makes a large difference in
initialization time.
These changes mostly move affinity code under a small class hierarchy:
KMPAffinity
class Mask {}
KMPNativeAffinity : public KMPAffinity
class Mask : public KMPAffinity::Mask
KMPHwlocAffinity
class Mask : public KMPAffinity::Mask
Since all interface functions (for both affinity and the mask implementation)
are virtual, the implementation can be chosen at runtime initialization.
Differential Revision: https://reviews.llvm.org/D26356
llvm-svn: 286890
This patch allows ThreadSanitizer (Tsan) to verify OpenMP programs.
It means that no false positive will be reported by Tsan when
verifying an OpenMP programs.
This patch introduces annotations within the OpenMP runtime module to
provide information about thread synchronization to the Tsan runtime.
In order to enable the Tsan support when building the runtime, you must
enable the TSAN_SUPPORT option with the following environment variable:
-DLIBOMP_TSAN_SUPPORT=TRUE
The annotations will be enabled in the main shared library
(same mechanism of OMPT).
Patch by Simone Atzeni and Joachim Protze!
Differential Revision: https://reviews.llvm.org/D13072
llvm-svn: 286115
UNICODE and _UNICODE defintions were added in the LLVM CMake build system.
While on Unices, the UNICODE/_UNICODE macros don't cause problems, on Windows
only ittnotify_static.c should be compiled using -DUNICODE. We are still
looking at a proper fix, but this change sets the build back to exactly what it
was doing before. Also, a comment and TODO were added in the src/CMakeLists.txt
file to help explain.
llvm-svn: 274052
That patch made all LLVM projects build with -DUNICODE. However, this doesn't
work for the OpenMP runtime.
But just overriding the flag with -UUNICODE breaks compiling ittnotify_static.c,
which for some reason needs to be compiled with -DUNICIODE. Note that compiling
ittnotify.h with -DUNICODE does not work though.
This seems like a mess. This commit fixes it for now, but it would be great
if someone who works on the OpenMP runtime could fix it properly.
llvm-svn: 273898
This patch allows a user to enable Hwloc on windows. There are three main
changes in here:
1.kmp.h - Move definitions/declarations out of KMP_OS_WINDOWS guard (our windows
implementation of affinity) because they need to be defined when
KMP_USE_HWLOC is on as well.
2.teach __kmp_set_system_affinity, __kmp_get_system_affinity,
__kmp_get_proc_group, and __kmp_affinity_bind_thread how to use hwloc.
3.teach CMake how to include hwloc when building Windows
Another minor change in here is to make sure that anything under KMP_USE_HWLOC
is also guarded by KMP_AFFINITY_SUPPORTED as well. This is to prevent Mac
builds from requiring anything from Hwloc.
Differential Revision: http://reviews.llvm.org/D21441
llvm-svn: 272951
OpenMP 4.1 is now OpenMP 4.5. Any mention of 41 or 4.1 is replaced with
45 or 4.5. Also, if the CMake option LIBOMP_OMP_VERSION is 41, CMake warns that
41 is deprecated and to use 45 instead.
llvm-svn: 272687
This change fixes the bug: https://llvm.org/bugs/show_bug.cgi?id=25975
by bypassing the perl module files which try to deduce system information.
These perl modules files don't offer useful information and are from the
original build system. They can be removed after this change.
llvm-svn: 258843
This change allows clang to build the stats library for every architecture
which supports __builtin_readcyclecounter(). CMake also checks for all
necessary features for stats and will error out if the platform does not
support it.
Patch by Hal Finkel and Johnny Peyton
llvm-svn: 256002
These changes allow libhwloc to be used as the topology discovery/affinity
mechanism for libomp. It is supported on Unices. The code additions:
* Canonicalize KMP_CPU_* interface macros so bitmask operations are
implementation independent and work with both hwloc bitmaps and libomp
bitmaps. So there are new KMP_CPU_ALLOC_* and KMP_CPU_ITERATE() macros and
the like. These are all in kmp.h and appropriately placed.
* Hwloc topology discovery code in kmp_affinity.cpp. This uses the hwloc
interface to create a libomp address2os object which the rest of libomp knows
how to handle already.
* To build, use -DLIBOMP_USE_HWLOC=on and
-DLIBOMP_HWLOC_INSTALL_DIR=/path/to/install/dir [default /usr/local]. If CMake
can't find the library or hwloc.h, then it will tell you and exit.
Differential Revision: http://reviews.llvm.org/D13991
llvm-svn: 254320
The problem is that the ompt_tool() function (which must be implemented by a
performance tool) should be defined in the RTL as well to cover the case when
the tool is not present in the address space of the process. This functionality
is accomplished with weak symbols in Unices. Unfortunately, Windows does not
support weak symbols.
The solution in these changes is to grab the list of all modules loaded by the
process and then search for symbol "ompt_tool()" within them. The function
ompt_tool_windows() performs the search of the ompt_tool symbol. If ompt_tool is
found, then its return value is used to initialize the tool. If ompt_tool is not
found, then ompt_tool_windows() returns NULL and OMPT is thus, disabled.
While doing these changes, the OMPT_SUPPORT detection in CMake was changed to
test for the required featuers for OMPT_SUPPORT, namely: builtin_frame_address()
existence, weak attribute existence and psapi.dll existence. For
LIBOMP_HAVE_OMPT_SUPPORT to be true, it must be that the builtin_frame_address()
intrinsic exists AND one of: either weak attributes exist or psapi.dll exists.
Also, since Process Status API is used I had to add new dependency -- psapi.dll
to the library dependency micro test.
Differential Revision: http://reviews.llvm.org/D14027
llvm-svn: 251654
Currently, the libomp CMake build system uses a Perl script to configure files
(tools/expand-vars.pl). This patch replaces the use of the Perl script by using
CMake's configure_file() function. The major changes include:
1. *.var has every $KMP_* variable changed to @LIBOMP_*@
2. kmp_config.h.cmake is a new file which contains all the feature macros and
#cmakedefine lines
3. Most of the -D lines have been moved from LibompDefinitions.cmake but some
OS specific MACROs (e.g., _GNU_SOURCE) remain.
4. All expand-vars.pl related logic is removed from the CMake files.
One important note about this change is that it breaks the old Perl+Makefile
build system because it can't create kmp_config.h properly.
Differential Review: http://reviews.llvm.org/D12211
llvm-svn: 246314
Two symbols for the external debugger support were incorrectly exported when LIBOMP_USE_DEBUGGER=off.
Differential Revision: http://reviews.llvm.org/D11763
llvm-svn: 244217
I was getting this cmake error on Mac OS X:
CMake Error: Error in cmake code at
/tmp/openmp/runtime/cmake/LibompMicroTests.cmake:140:
Parse error. Function missing ending ")". Instead found bad character with text "[".
Perhaps invoking 'test' is less confusing for cmake.
Differential Revision: http://reviews.llvm.org/D11493
llvm-svn: 243165
libomp_check_linker_flag rewrites src_to_link.c and CMakeLists.txt in build
directory for test project, but cmake does not rebuild the project. The root
cause is that on some filesystems (ext3, reiserfs) timestamp resoultion is 1
second. So cmake does not rebuild test project if check takes less than 1 second.
This patch puts each test in its own directory to avoid the timestamp problem.
Patch by Chris Bergstrom
http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-July/000817.html
llvm-svn: 243017
clean up the build.
This disables all of the Clang warnings that fire for me when building
libomp.so on Linux with a recent Clang binary. Lots of these should
probably be fixed, but I want to at least get the build warning-clean
and make it easy to keep that way.
I also switched a bunch of the warnings that are used both for C and C++
compiles to check the flag with C compilation test.
Differential Revision: http://reviews.llvm.org/D11253
llvm-svn: 242604
I apologize for this nasty commit, but I somehow overlooked Chandler's
comment to re-indent these files to two space indention. I know this
is a horrible commit, but I figured if it was done quickly after the
first one, not too many conflicts would arise.
Again, I'm sorry and won't do this again.
llvm-svn: 242301
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
These changes enable external debuggers to conveniently interface with
the LLVM OpenMP Library. Structures are added which describe the important
internal structures of the OpenMP Library e.g., teams, threads, etc.
This feature is turned on by default (CMake variable LIBOMP_USE_DEBUGGER)
and can be turned off with -DLIBOMP_USE_DEBUGGER=off.
Differential Revision: http://reviews.llvm.org/D10038
llvm-svn: 241832
Add new LIBOMP_ENABLE_ASSERTIONS macro which can be set in a standalone build
or takes the value of LLVM_ENABLE_ASSERTIONS when inside llvm/projects. This
change also defines the KMP_BUILD_ASSERT() macro to do nothing when ENABLE_ASSERTIONS
is off. This means the __kmp_build_check_* types won't be defined and thus, no warnings.
http://lists.cs.uiuc.edu/pipermail/openmp-dev/2015-June/000719.html
Patch by Jack Howarth and Jonathan Peyton
llvm-svn: 239546
Most CMake build systems put CMakeLists.txt files inside source directories where
items need to get built. This change follows that convention by adding a new
runtime/src/CMakeLists.txt file. An additional benefit is this helps logically
seperate configuring with building as well. This change is mostly just copying and
pasting the bottom half of runtime/CMakeLists.txt into runtime/src/CMakeLists.txt,
but a few changes had to be made to get it to work. Most of those changes were to
directory prefixes.
Differential Revision: http://reviews.llvm.org/D10344
llvm-svn: 239542
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
A while back, Hal suggested updating the GUIDEDLL_EXPORTS macro guard to
a more descriptive name. It represents a dynamic library build so
KMP_DYNAMIC_LIB is a more suitable name.
Differential Revision: http://reviews.llvm.org/D9899
llvm-svn: 238221
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
This patch integrates the libiomp CMake build system into the LLVM CMake build
system so that users can checkout libiomp into the projects directory of llvm
and build llvm,clang, and libiomp all together. These changes specifically
introduce a new install target which will put libraries and headers into the
correct locations when either a standalone build or part of llvm.
The copy_recipe() method has been removed in favor of the POST_BUILD method
to move headers into the exports subdirectory. And lastly, the MicroTests.cmake
file was refactored which led to simpler target dependencies and a new target,
make libiomp-micro-tests, which performs the 5 small tests (test-relo,
test-touch, etc.) when called.
llvm-svn: 236534