Page MenuHomePhabricator

[OpenMP] Initial implementation of OMP 5.0 Memory Management routines
ClosedPublic

Authored by jlpeyton on Aug 24 2018, 1:29 PM.

Details

Summary

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

Diff Detail

Repository
rL LLVM

Event Timeline

jlpeyton created this revision.Aug 24 2018, 1:29 PM
jlpeyton edited the summary of this revision. (Show Details)Aug 24 2018, 1:55 PM
Hahnfeld added inline comments.
runtime/src/kmp_alloc.cpp
1318–1323 ↗(On Diff #162465)

Does that mean we return NULL if allocator == omp_high_bw_mem_alloc && !__kmp_hbw_mem_available? Would it make sense to fallback to omp_default_mem_alloc in this case?

runtime/tools/generate-def.pl
113–123 ↗(On Diff #162465)

Can the commented lines be removed?

kkwli0 added a subscriber: kkwli0.Aug 26 2018, 6:46 PM
AndreyChurbanov added inline comments.
runtime/src/kmp_alloc.cpp
1318–1323 ↗(On Diff #162465)

The "return NULL" id the requirement of the current OpenMP spec TRF6 (Nov 2017) which current change is related to. Next version - TR7 draft (and the following OpenMP 5.0 to be released in Nov 2018) - does not have this requirement, but also has some extensions to implement in runtime (custom memory allocators). So the plan is to consider the different default policy with future patch that implements OpenMP 5.0 extensions. Next versions of the specification will have further extensions (custom memory spaces); we won't start implementing them until we get more details.

Hahnfeld added inline comments.Aug 27 2018, 9:49 AM
runtime/src/kmp_alloc.cpp
1318–1323 ↗(On Diff #162465)

I see: The fallback trait is an extension of TR7. For reference its default value appears to be default_mem_fb (so my intuition was correct) but that doesn't matter if this patch implements the behavior defined by TR6.

jlpeyton updated this revision to Diff 163921.Sep 4 2018, 2:24 PM

Removed commented lines from generate-def.pl

hbae accepted this revision.Sep 4 2018, 2:28 PM

LGTM.

This revision is now accepted and ready to land.Sep 4 2018, 2:28 PM
This revision was automatically updated to reflect the committed changes.

This commit is bit damaging for those who want to use libomp.a for -static built applications. As KMP_DYNAMIC_LIB is hardcoded to 1 in kmp_config.h.cmake, dlopen will always be used causing following link-time warning:

warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

This makes virtually impossible to copy libomp.a across various Linux boxes or shipping libomp.a in binary libomp packages addressed to various Linux systems.