[Openmp-commits] [PATCH] D51232: [OpenMP] Initial implementation of OMP 5.0 Memory Management routines

Jonas Hahnfeld via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Mon Aug 27 09:49:06 PDT 2018


Hahnfeld added inline comments.


================
Comment at: runtime/src/kmp_alloc.cpp:1318-1323
+  if (allocator == omp_default_mem_alloc)
+    ptr = __kmp_allocate(desc.size_a);
+  if (allocator == omp_high_bw_mem_alloc && __kmp_hbw_mem_available) {
+    KMP_DEBUG_ASSERT(p_hbw_malloc != NULL);
+    ptr = p_hbw_malloc(desc.size_a);
+  }
----------------
AndreyChurbanov wrote:
> Hahnfeld wrote:
> > 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?
> 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.
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.


Repository:
  rOMP OpenMP

https://reviews.llvm.org/D51232





More information about the Openmp-commits mailing list