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

[Shilei Tian via Phabricator via Openmp-commits]

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,
+      KMP_ALLOCATOR_MAX_HANDLE = UINTPTR_MAX
+    } 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.


Repository:
  rOMP OpenMP

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59783/new/

https://reviews.llvm.org/D59783