summaryrefslogtreecommitdiff
path: root/openmp/runtime/src/kmp_alloc.cpp
AgeCommit message (Collapse)Author
2025-10-15[OpenMP] Fix preprocessor mismatches between include and usages of hwloc ↵Peter Arzt
(#158349) Fix https://github.com/llvm/llvm-project/issues/156679 There is a mismatch between the preprocessor guards around the include of `hwloc.h` and those protecting its usages, leading to build failures on Darwin: https://github.com/spack/spack-packages/pull/1212 This change introduces `KMP_HWLOC_ENABLED` that reflects whether hwloc is actually used.
2025-06-25[OpenMP] Fix various alignment issues (#142376)Rainer Orth
When running the `openmp` testsuite on 32-bit SPARC, several tests `FAIL` apparently randomly, but always with the same kind of error: ``` # error: command failed with exit status: -11 ``` The tests die with `SIGBUS`, as can be seen in `truss` output: ``` 26461/1: Incurred fault #5, FLTACCESS %pc = 0x00010EAC 26461/1: siginfo: SIGBUS BUS_ADRALN addr=0x0013D12C 26461/1: Received signal #10, SIGBUS [default] 26461/1: siginfo: SIGBUS BUS_ADRALN addr=0x0013D12C ``` i.e. the code is trying an unaligned access which cannot work on SPARC, a strict-alignment target which enforces natural alignment on access. This explains the apparent randomness of the failures: if the memory happens to be aligned appropriately, the tests work, but fail if not. A `Debug` build reveals much more: - `__kmp_alloc` currently aligns to `sizeof(void *)`, which isn't enough on strict-alignment targets when the data are accessed as types requiring larger alignment. Therefore, this patch increases `alignment` to `SizeQuant`. - 32-bit Solaris/sparc `libc` guarantees 8-byte alignment from `malloc`, so this patch adjusts `SizeQuant` to match. - There's a `SIGBUS` in ``` __kmpc_fork_teams (loc=0x112f8, argc=0, microtask=0x16cc8 <__omp_offloading_ffbc020a_4b1abe_main_l9_debug__.omp_outlined>) at openmp/runtime/src/kmp_csupport.cpp:573 573 *(kmp_int64 *)(&this_thr->th.th_teams_size) = 0L; ``` Casting to a pointer to a type requiring 64-bit alignment when that isn't guaranteed is wrong. Instead, this patch uses `memset` instead. - There's another `SIGBUS` in ``` 0xfef8cb9c in __kmp_taskloop_recur (loc=0x10cb8, gtid=0, task=0x23cd00, lb=0x23cd18, ub=0x23cd20, st=1, ub_glob=499, num_tasks=100, grainsize=5, extras=0, last_chunk=0, tc=500, num_t_min=20, codeptr_ra=0xfef8dbc8 <__kmpc_taskloop(ident_t*, int, kmp_task_t*, int, kmp_uint64*, kmp_uint64*, kmp_int64, int, int, kmp_uint64, void*)+240>, task_dup=0x0) at openmp/runtime/src/kmp_tasking.cpp:5147 5147 p->st = st; ``` `p->st` doesn't currently guarantee the 8-byte alignment required by `kmp_int64 st`. `p` is set in ``` __taskloop_params_t *p = (__taskloop_params_t *)new_task->shareds; ``` but `shareds_offset` is currently aligned to `sizeof(void *)` only. Increasing it to `sizeof(kmp_uint64)` to match its use fixes the `SIGBUS`. With these fixes I get clean `openmp` test results on 32-bit SPARC (both Solaris and Linux), with one unrelated exception. Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`, `sparc-unknown-linux-gnu`, `sparc64-unknown-linux-gnu`, `i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and `x86_64-pc-linux-gnu`.
2025-04-02[OpenMP] 6.0 (TR11) Memory Management Update (#97106)Hansang Bae
TR11 introduced changes to support target memory management in a unified way by defining a series of API routines and additional traits. Host runtime is oblivious to how actual memory resources are mapped when using the new API routines, so it can only support how the composed memory space is maintained, and the offload backend must handle which memory resources are actually used to allocate memory from the memory space. Here is summary of the implementation. * Implemented 12 API routines to get/mainpulate memory space/allocator. * Memory space composed with a list of devices has a state with resource description, and runtime is responsible for maintaining the allocated memory space objects. * Defined interface with offload runtime to access memory resource list, and to redirect calls to omp_alloc/omp_free since it requires backend-specific information. * Value of omp_default_mem_space changed from 0 to 99, and omp_null_mem_space took the value 0 as defined in the language. * New allocator traits were introduced, but how to use them is up to the offload backend. * Added basic tests for the new API routines.
2025-04-02[OpenMP] Add memory allocation using hwloc (#132843)nawrinsu
This patch adds support for memory allocation using hwloc. To enable memory allocation using hwloc, env KMP_TOPOLOGY_METHOD=hwloc needs to be used. If hwloc is not supported/available, allocation will fallback to default path.
2023-02-22[OpenMP] Target memory allocator fallback to default when no device availableNawrin Sultana
Differential Revision: https://reviews.llvm.org/D144525
2023-02-13[OpenMP] Add check for target allocator regardless of the availability of ↵Nawrin Sultana
libmemkind Current runtime implementation only checks for target allocator when libmemkind is not available. This patch adds checks for target allocator regardless of the presence of libmemkind library. Differential Revision: https://reviews.llvm.org/D142582
2023-01-13[OpenMP][libomptarget][AMDGPU] lock/unlock (pin/unpin) mechanism in ↵Carlo Bertolli
libomptarget amdgpu plugin (API and implementation) The current only way to obtain pinned memory with libomptarget is to use a custom allocator llvm_omp_target_alloc_host. This reflects well the CUDA implementation of libomptarget, but it does not correctly expose the AMDGPU runtime API, where any system allocated page can be locked/unlocked through a call to hsa_amd_memory_lock/unlock. This patch enables users to allocate memory through malloc (mmap, sbreak) and then pin the related memory pages with a libomptarget special call. It is a base support in the amdgpu libomptarget plugin to enable users to prelock their host memory pages so that the runtime doesn't need to lock them itself for asynchronous memory transfers. Reviewed By: jdoerfert, ye-luo Differential Revision: https://reviews.llvm.org/D139208
2022-12-14[OpenMP] Add API for pinned memoryCarlo Bertolli
This patch adds API support for the atk_pinned trait for omp_alloc. It does not implement kmp_target_lock_mem and kmp_target_unlock_mem in libomptarget, but prepares libomp for it. Patches to libomptarget to implement lock/unlock coming after this one. Reviewed by: jlpeyton, jdoerfert Differential Revision: https://reviews.llvm.org/D138933
2022-12-05[OpenMP] Let predefined allocator fallback to default instead of returning nullNawrin Sultana
Differential Revision: https://reviews.llvm.org/D139376
2022-09-14[Libomptarget] Change device free routines to accept the allocation kindJoseph Huber
Previous support for device memory allocators used a single free routine and did not provide the original kind of the allocation. This is problematic as some of these memory types required different handling. Previously this was worked around using a map in runtime to record the original kind of each pointer. Instead, this patch introduces new free routines similar to the existing allocation routines. This allows us to avoid a map traversal every time we free a device pointer. The only interfaces defined by the standard are `omp_target_alloc` and `omp_target_free`, these do not take a kind as `omp_alloc` does. The standard dictates the following: "The omp_target_alloc routine returns a device pointer that references the device address of a storage location of size bytes. The storage location is dynamically allocated in the device data environment of the device specified by device_num." Which suggests that these routines only allocate the default device memory for the kind. So this has been changed to reflect this. This change is somewhat breaking if users were using `omp_target_free` as previously shown in the tests. Reviewed By: JonChesterfield, tianshilei1992 Differential Revision: https://reviews.llvm.org/D133053
2022-06-02[OpenMP][libomp] do not try to dlopen libmemkind on macOSDaniel Douglas
The memkind library is only available for linux. Calling dlopen here can also be problematic in a client app that fork'ed. Differential Revision: https://reviews.llvm.org/D126579
2022-04-07[OpenMP] Change target memory tests to use allocatorsJoseph Huber
The target allocators have been supported for NVPTX offloading for awhile. The tests should use the allocators instead of calling the functions manually. Also the comments indicating these being a preview should be removed. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D123242
2021-10-11[OpenMP] libomp: add OpenMP 5.1 memory allocation routines.AndreyChurbanov
Aligned allocation routines added. Fortran interfaces added for all allocation routines. Differential Revision: https://reviews.llvm.org/D110923
2021-08-16[OpenMP] libomp: cleanup: minor fixes to silence static analyzer.AndreyChurbanov
Added couple more checks to silence KlocWork static code analyzer. Differential Revision: https://reviews.llvm.org/D107348
2021-07-30[OpenMP][NFC] libomp: silence warnings on unused variables.AndreyChurbanov
Put declarations/definitions of unused variables under corresponding macros to silence clang build warnings. Differential Revision: https://reviews.llvm.org/D106608
2021-03-02[OpenMP] Add allocator support for target memoryHansang Bae
This is a preview of allocator support for target memory that depends on the offload runtime API which allocates memory as described below. llvm_omp_target_alloc_host(size_t size, int device_num); -- Returns non-migratable memory owned by host. -- Memory is accessible by host and device(s). llvm_omp_target_alloc_shared(size_t size, int device_num); -- Returns migratable memory owned by host and device. -- Memory is accessible by host and device. llvm_omp_target_alloc_device(size_t size, int device_num); -- Returns memory owned by device. -- Memory is only accessible by device. New memory space and predefined allocator names are -- llvm_omp_target_host_mem_space -- llvm_omp_target_shared_mem_space -- llvm_omp_target_device_mem_space -- llvm_omp_target_host_mem_alloc -- llvm_omp_target_shared_mem_alloc -- llvm_omp_target_device_mem_alloc Differential Revision: https://reviews.llvm.org/D96669
2021-02-20[OpenMP][NFC] clang-format the whole openmp projectShilei Tian
Same script as D95318. Test files are excluded. Reviewed By: AndreyChurbanov Differential Revision: https://reviews.llvm.org/D97088
2021-01-12[OpenMP] Use persistent memory for omp_large_cap_memHansang Bae
This change enables volatile use of persistent memory for omp_large_cap_mem* on supported systems. It depends on libmemkind's support for persistent memory, and requirements/details can be found at the following url. https://pmem.io/2020/01/20/memkind-dax-kmem.html Differential Revision: https://reviews.llvm.org/D94353
2021-01-12[OpenMP] Update allocator trait key/value definitionsHansang Bae
Use new definitions introduced in 5.1 specification. Differential Revision: https://reviews.llvm.org/D94277
2020-12-31[OpenMP] libomp: Handle implicit conversion warningsTerry Wilmarth
This patch partially prepares the runtime source code to be built with -Wconversion, which should trigger warnings if any implicit conversions can possibly change a value. For builds done with icc or gcc, all such warnings are handled in this patch. clang gives a much longer list of warnings, particularly for sign conversions, which the other compilers don't report. The -Wconversion flag is commented into cmake files, but I'm not going to turn it on. If someone thinks it is important, and wants to fix all the clang warnings, they are welcome to. Types of changes made here involve either improving the consistency of types used so that no conversion is needed, or else performing careful explicit conversions, when we're sure a problem won't arise. Patch is a combination of changes by Terry Wilmarth and Johnny Peyton. Differential Revision: https://reviews.llvm.org/D92942
2020-11-17[OpenMP] Add omp_realloc implementationNawrin Sultana
This patch adds omp_realloc function implementation according to OpenMP 5.1 specification. Differential Revision: https://reviews.llvm.org/D90971
2020-11-13[OpenMP] Add omp_calloc implementationNawrin Sultana
This patch adds omp_calloc implementation according to OpenMP 5.1 specification. Differential Revision: https://reviews.llvm.org/D90967
2020-04-04[OpenMP] NFC: Fix trivial typoKazuaki Ishizaki
Differential Revision: https://reviews.llvm.org/D77430
2020-01-23[OpenMP] change omp_atk_* and omp_atv_* enumerators to lowercase [NFC]Kelvin Li
The OpenMP spec defines the OMP_ATK_* and OMP_ATV_* to be lowercase. Differential Revision: https://reviews.llvm.org/D73248
2020-01-03[OpenMP] NFC: Fix trivial typos in commentsKelvin Li
Submitted by: kiszk Differential Revision: https://reviews.llvm.org/D72171
2019-07-12[OpenMP] Remove OMP spec versioningJonathan Peyton
Remove all older OMP spec versioning from the runtime and build system. Patch by Terry Wilmarth Differential Revision: https://reviews.llvm.org/D64534 llvm-svn: 365963
2019-04-08[OpenMP] Implement 5.0 memory managementJonathan Peyton
* Replace HBWMALLOC API with more general MEMKIND API, new functions and variables added. * Have libmemkind.so loaded when accessible. * Redirect memspaces to default one except for high bandwidth which is processed separately. * Ignore some allocator traits e.g., sync_hint, access, pinned, while others are processed normally e.g., alignment, pool_size, fallback, fb_data, partition. * Add tests for memory management Patch by Andrey Churbanov Differential Revision: https://reviews.llvm.org/D59783 llvm-svn: 357929
2019-01-19Update more file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-09-07[OpenMP] Initial implementation of OMP 5.0 Memory Management routinesJonathan Peyton
Implemented omp_alloc, omp_free, omp_{set,get}_default_allocator entries, and OMP_ALLOCATOR environment variable. Added support for HBW memory on Linux if libmemkind.so library is accessible (dynamic library only, no support for static libraries). Only used stable API (hbwmalloc) of the memkind library though we may consider using experimental API in future. The ICV def-allocator-var is implemented per implicit task similar to place-partition-var. In the absence of a requested allocator, the uses the default allocator. Predefined allocators (the only ones currently available) are made similar for C and Fortran, - pointers (long integers) with values 1 to 8. Patch by Andrey Churbanov Differential Revision: https://reviews.llvm.org/D51232 llvm-svn: 341687
2018-08-09[OpenMP] Cleanup codeJonathan Peyton
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
2018-07-26PR30734: Remove __kmp_ft_page_allocate()Jonas Hahnfeld
This function was not enabled by default and not exported when manually tweaking the build flags. Additionally it was hard to use since there is no corresponding __kmp_ft_page_free(). The code itself is questionable because the returned memory address is padded by an extra pointer which stores the unpadded start of the allocated region (this would need to be freed). Differential Revision: https://reviews.llvm.org/D49802 llvm-svn: 338052
2017-10-20Apply formatting changesJonathan Peyton
.clang-format's comments are removed and a (hopefully) final set of formatting changes are applied. Differential Revision: https://reviews.llvm.org/D38837 Differential Revision: https://reviews.llvm.org/D38920 llvm-svn: 316227
2017-09-27Remove unnecessary semicolonsJonathan Peyton
Removes semicolons after if {} blocks, function definitions, etc. I was able to apply the large OMPT patch cleanly on top of this one with no conflicts. llvm-svn: 314340
2017-07-17OpenMP RTL cleanup: eliminated warnings with -Wcast-qual, patch 2.Andrey Churbanov
Changes are: got all atomics to accept volatile pointers that allowed to simplify many type conversions. Windows specific code fixed correspondingly. Differential Revision: https://reviews.llvm.org/D35417 llvm-svn: 308164
2017-07-07remove deprecated register storage class specifierEd Maste
While importing libomp into the FreeBSD base system we encountered Clang warnings that "'register' storage class specifier is deprecated and incompatible with C++1z [-Wdeprecated-register]". Differential Revision: https://reviews.llvm.org/D35124 llvm-svn: 307441
2017-07-03OpenMP RTL cleanup: eliminated warnings with -Wcast-qual.Andrey Churbanov
Changes are: replaced C-style casts with cons_cast and reinterpret_cast; type of several counters changed to signed; type of parameters of 32-bit and 64-bit AND and OR intrinsics changes to unsigned; changed files formatted using clang-format version 3.8.1. Differential Revision: https://reviews.llvm.org/D34759 llvm-svn: 307020
2017-05-12Clang-format and whitespace cleanup of source codeJonathan Peyton
This patch contains the clang-format and cleanup of the entire code base. Some of clang-formats changes made the code look worse in places. A best effort was made to resolve the bulk of these problems, but many remain. Most of the problems were mangling line-breaks and tabbing of comments. Patch by Terry Wilmarth Differential Revision: https://reviews.llvm.org/D32659 llvm-svn: 302929
2016-12-14Follow up to r289732: Update comments in source files to reference .cpp filesJonathan Peyton
Patch by Hansang Bae llvm-svn: 289739
2016-12-14Change source files from .c to .cppJonathan Peyton
Patch by Hansang Bae Differential Revision: https://reviews.llvm.org/D26688 llvm-svn: 289732