[Openmp-commits] [PATCH] D59783: [OpenMP] Implement 5.0 memory management

Shilei Tian via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Fri Jan 20 19:02:19 PST 2023

tianshilei1992 added inline comments.
Herald added subscribers: sstefan1, yaxunl.
Herald added a reviewer: jdoerfert.
Herald added a project: All.

Comment at: runtime/src/include/50/omp.h.var:299
+      omp_thread_mem_alloc = 8,
+    } omp_allocator_handle_t;
This enum causes the front end some troubles.
extern int printf(const char *, ...);

typedef enum omp_allocator_handle_t {
  omp_null_allocator = 0,
  omp_default_mem_alloc = 1,
  omp_large_cap_mem_alloc = 2,
  omp_const_mem_alloc = 3,
  omp_high_bw_mem_alloc = 4,
  omp_low_lat_mem_alloc = 5,
  omp_cgroup_mem_alloc = 6,
  omp_pteam_mem_alloc = 7,
  omp_thread_mem_alloc = 8,
  llvm_omp_target_host_mem_alloc = 100,
  llvm_omp_target_shared_mem_alloc = 101,
  llvm_omp_target_device_mem_alloc = 102,
  KMP_ALLOCATOR_MAX_HANDLE = 18446744073709551615UL
} omp_allocator_handle_t;

int main(int argc, char *argv[]) {
  printf("sizeof(omp_allocator_handle_t)=%zu, sizeof(omp_null_allocator)=%zu\n",
         sizeof(omp_allocator_handle_t), sizeof(omp_null_allocator));
  return 0;
This simple code shows that `sizeof(omp_allocator_handle_t)=8`, while `sizeof(omp_null_allocator)=4`. It is not safe to assume that all members of the enum will be of the same type as `omp_allocator_handle_t`. It's not generally a problem at runtime, but things are messed up in front end if user uses allocators.

In clang, in order to determine the type of `omp_allocator_handle_t`, clang checks the type of those predefined allocators. The first one it checks is `omp_null_allocator`. What clang gets is a `int`, instead of an enum of size 8. If the allocator is captured by a region, let's say a parallel region, the allocator will be privatized. Because clang deems `omp_allocator_handle_t` as an `int`, it will first cast the value returned by runtime (for `libomp` it is a `void *`) to `int`, and then in the outlined function, it casts the `int` back to `omp_allocator_handle_t`. This two casts completely shaves the first 32-bit of the pointer, and when the private "new" pointer is fed to another runtime function call `__kmpc_allocate()`, it causes segment fault.

Can we define those allocators like how they are defined on Windows, aka global variables? This can make sure the size is fixed.

  rOMP OpenMP



More information about the Openmp-commits mailing list