This option is legacy and is removed from GNU ld's doc (many binutils
distributions are configured with --enable-textrel-check=). lld ignores the
option.
This fixes warnings like this:
```
openmp/runtime/test/omp_testsuite.h:107:60: warning: format specifies type 'unsigned int' but the argument has type 'DWORD' (aka 'unsigned long') [-Wformat]
fprintf(stderr, "CreateThread() failed: Error #%u.\n", GetLastError());
~~ ^~~~~~~~~~~~~~
%lu
```
Differential Revision: https://reviews.llvm.org/D137747
Clang does accept the flag for any architecture, but prints a
warning:
clang-16: warning: argument unused during compilation: '-mrtm' [-Wunused-command-line-argument]
This flag is documented as an x86 specific flag, so don't try to
add it for other architectures, to silence this warning.
Differential Revision: https://reviews.llvm.org/D137744
In D135552 the #else is added, which causes build error when
building openmp on RISCV64. This patch fixed the error:
"Unknown or unsupported architecture"
Reviewed By: pirama
Differential Revision: https://reviews.llvm.org/D138241
The hidden helper task is only enabled on Linux (kmp_runtime.cpp
initializes __kmp_enable_hidden_helper to TRUE for linux but to
FALSE for any other OS), and the __kmp_stg_parse_use_hidden_helper
function always makes it disabled on non-Linux OSes too.
Add a lit test feature for hidden helper tasks (only made available
on Linux) and mark two tests as requiring this feature.
Disable hidden helper tasks in the test that doesn't really involve
them, for consistent behaviour across platforms.
Differential Revision: https://reviews.llvm.org/D137749
In D135552 the #else is added, which causes build error when
building openmp on LoongArch. This patch fixed the error:
"Unknown or unsupported architecture"
Reviewed By: SixWeining, MaskRay
Differential Revision: https://reviews.llvm.org/D137604
This effectively reverts 6f9e25d382.
I didn't follow the complete history, but it seems this was added due
to AArch64's output changing in some fallback. Blockaddress definitely
works now, so just remove this.
Summary:
This header file uses the `DP` prefixes but does not define
`DEBUG_PREFIX`. This patch adds a simple fix, but realistically the `DP`
system isn't ideal. Now that we have access to LLVM libraries and other
utilities we should consider rewriting all of the debugging and error
handling glue.
Summary:
This commit sets the default visibility of PluginInterface's symbols (in
nextgen plugins) as protected. This prevents symbols from a plugin
library to be preempted by another plugin library's symbol. It applies
the same fix introduced by D136365.
Issue reported by @ggeorgakoudis.
Differential Revision: https://reviews.llvm.org/D138002
This is part of a set of patches implementing OMPT target callback support and has been split out of the originally submitted https://reviews.llvm.org/D113728. The overall design can be found in https://rice.app.box.com/s/pf3gix2hs4d4o1aatwir1set05xmjljc
The purpose of this patch is to provide a way to register tool-provided callbacks into libomp when libomptarget is loaded.
Introduced a cmake variable LIBOMPTARGET_OMPT_SUPPORT that can be used to control OMPT target support. It follows host OMPT support, controlled by LIBOMP_HAVE_OMPT_SUPPORT.
Added a connector that can be used to communicate between OMPT implementations in libomp and libomptarget or libomptarget and a plugin.
Added a global constructor in libomptarget that uses the connector to force registration of tool-provided callbacks in libomp. A pair of init and fini functions are provided to libomp as part of the connect process which will be used to register the tool-provided callbacks in libomptarget.
Patch from John Mellor-Crummey <johnmc@rice.edu>
(With contributions from Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>)
Reviewed By: dreachem, jhuber6
Differential Revision: https://reviews.llvm.org/D123572
Summary:
The changes in D125860 renamed the old resource directory to only use
the major version. This was not updated for the OpenMP project, causing
OpenMP resources to still be installed in the old `major.minor.rev`
folder. This lead to problems including the header files.
fixes#58966
OpenMP tests that use pthread functions include this header instead.
On Unix systems, this header includes pthread.h, while it provides
minimal implementations of the used pthread functions for Windows.
Differential Revision: https://reviews.llvm.org/D137746
Add a missing <process.h> include for _getpid. Don't typedef the
pid_t type on mingw, as mingw headers already provide a typedef for
it.
Differential Revision: https://reviews.llvm.org/D137745
This patch changes AArch64 + `__GNUC__` to use `__sync` builtins to
implement internal atomic macros just like for Unix, because mingw-w64
is missing some of the intrinsics which the MSVC codepath is using.
Then some remaining intel-only functions are removed from dllexport to
fix linking.
This should fix https://github.com/llvm/llvm-project/issues/56349.
Reviewed By: natgla
Differential Revision: https://reviews.llvm.org/D137168
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
Issue #58858: when linking libomp.so, exports_so.txt has non-existent/undefined
symbols which cause errors to ld --no-undefined-version. Use
-Wl,--undefined-version if available (gold, ld.lld, future GNU ld 2.40).
But I can not reproduce the problem on my local machine. My local machine run:
222 0x5a6780
222 0x7fffbef9400e
222 0x5a677e 0x5a6780 0x7fffbef936c8
222 0x376f8e 0x376f90 0x7fffbef94008
222 0x281f20
222 0x7fffbef9400e
PASSED
It is caused by regenerate captured var value when processing the
has_device_addr, the captured var value has been generated in
GenerateOpenMPCapturedVars and passed as Arg in generateInfoForCapture.
The fix just use Arg instead regenerated just same as is_device_ptr
Now we state that backward compatibility is not guaranteed in the document.
Reviewed By: JonChesterfield, dreachem
Differential Revision: https://reviews.llvm.org/D133277
Fix setting affinity type and topology method when affinity is disabled
and fix places that were not taking into account that affinity can be
explicitly disabled by putting proper KMP_AFFINITY_CAPABLE() check.
Differential Revision: https://reviews.llvm.org/D137176
The AsyncInfoTy should be created in the same device as the async operation will be issued. In omp_target_memcpy, the AsyncInfoTy for the host to destination device transfer was created referring to the source device.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D137225
This is part of a set of patches implementing OMPT target callback support and has been split out of the originally submitted https://reviews.llvm.org/D113728. The overall design can be found in https://rice.app.box.com/s/pf3gix2hs4d4o1aatwir1set05xmjljc
The purpose of this patch is to provide a way to register tool-provided callbacks into libomp when libomptarget is loaded.
Introduced a cmake variable LIBOMPTARGET_OMPT_SUPPORT that can be used to control OMPT target support. It follows host OMPT support, controlled by LIBOMP_HAVE_OMPT_SUPPORT.
Added a connector that can be used to communicate between OMPT implementations in libomp and libomptarget or libomptarget and a plugin.
Added a global constructor in libomptarget that uses the connector to force registration of tool-provided callbacks in libomp. A pair of init and fini functions are provided to libomp as part of the connect process which will be used to register the tool-provided callbacks in libomptarget.
Depends on D123429
Patch from John Mellor-Crummey <johnmc@rice.edu>
(With contributions from Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>)
Reviewed By: dreachem
Differential Revision: https://reviews.llvm.org/D123572
When multiple threads invoke checkDeviceAndCtors, both of them may read true
from the shared variable Device.HasPendingGlobals, and then invoke initLibrary
redundantly. Therefore only protecting the access to Device.HasPendingGlobals
is not sufficient to guarantee that initLibrary is invoked just once.
To fix this race condition, we move the invocation of initLibrary into the
critical section, and remove the same lock inside initLibrary.
Differential Revision: https://reviews.llvm.org/D136952
Place various classes/structs into anonymous namespaces and mark
variables as static. As far as I understand, these are all
implementation details and not intended to be exported -- only a
small number of tsan hooks are supposed to be.
Differential Revision: https://reviews.llvm.org/D136845
Add new hidden helper affinity via the environment variable,
KMP_HIDDEN_HELPER_AFFINITY, which allows users to assign thread
affinity to hidden helper threads using the same syntax as
KMP_AFFINITY. OMP_PLACES/OMP_PROC_BIND have no interaction with
KMP_HIDDEN_HELPER_AFFINITY.
Differential Revision: https://reviews.llvm.org/D135113
Separate change for the warnings to depend on the relevant affinity
settings verbose and warnings settings.
Differential Revision: https://reviews.llvm.org/D135112
This patch parameterizes the affinity initialization code to allow multiple
affinity settings. Almost all global affinity settings are consolidated
and put into a structure kmp_affinity_t. This is in anticipation of the
addition of hidden helper affinity which will have the same syntax and
semantics as KMP_AFFINITY only for the hidden helper team.
Differential Revision: https://reviews.llvm.org/D135109
Need both add_custom_command to resolve file-level dependency and add_custom_target to resolve target-level dependency.
From CMake add_custom_command doc:
Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use the add_custom_target() command to drive the command and make the other targets depend on that one).
${CMAKE_CURRENT_BINARY_DIR}/${bclib_name} is used by multiple targets and thus requires a custom target to avoid racing.
Differential Revision: https://reviews.llvm.org/D136911
This patch adds a new infrastructure for OpenMP target plugins. It also implements the CUDA and GenericELF64bit plugins under this new infrastructure. We place the sources in a separate directory named plugins-nextgen, and we build the new plugins as different plugin libraries. The original plugins, which remain untouched, will be used by default. However, the user can change this behavior at run-time through the boolean envar LIBOMPTARGET_NEXTGEN_PLUGINS. If enabled, the libomptarget will try to load the NextGen version of each plugin, falling back to the original if they are not present or valid.
The idea of this new plugin infrastructure is to implement the common parts of target plugins in generic classes (defined in files inside plugins-next/common/PluginInterface folder), and then, each specific plugin defines its own specific classes inheriting from the common ones. In this way, most logic remains on the common interface while reducing the plugin-specific source code. It is also beneficial in the sense that now most code and behavior are the same across the different plugins. As an example, we define classes for a plugin, a device, a device image, a stream manager, etc. The plugin object (a single instance per plugin library) holds different device objects (i.e., one per available device), while these latter are the responsible for managing its own resources.
Most code on this patch is based on the changes made by @jdoerfert (Johannes Doerfert)
Reviewed By: jhuber6, jdoerfert
Differential Revision: https://reviews.llvm.org/D134396
When detect __NR_sched_getaffinity. the last #else is missing,
which make the last platform MIPS64 failed to build with an error:
"Unknown or unsupported architecture"
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135552
The plugins all define the same interface symbols. This is generally not
a problem when calling the plugin directly from the dynamic library's
handle. However, when calling from within the plugin itself it is
possible for another plugin's symbols to preempt the symbols. This was
observed with the `__tgt_rtl_is_valid_binary` call in the
`__tgt_rtl_is_valid_binary_info` function being mapped to the x86_64
plugin.
This patch changes the default visibility to `protected` intead. This
visibility ensures that these symbols are all externally visible from
the plugin, but ensures their definitions are fixed within the shared
library. Having protected visiiblity makes such symbol preemption
impossible.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D136365
Fangrui Song