[Openmp-dev] Libomptarget fatal error 1: '#pragma omp requires unified_shared_memory' not used consistently!

Joachim Protze via Openmp-dev openmp-dev at lists.llvm.org
Tue Mar 2 08:45:39 PST 2021


Am 02.03.21 um 15:58 schrieb Alexey.Bataev:
> Ye, generally speaking stack allocations can be replaced by managed mem
> allocation. We have very similar functionality for #pragma omp allocate,
> where static alloca can be replaced by __kmpc_alloc calls. But, most
> probably, it would be good to extend #pragma omp allocate to add managed
> memory support. Otherwise it would hard to implement it. Or it can be
> implemented in the backend by adding analysis/transformation of static
> allocas into managed memory alloc calls if it is proved that the
> variable is supposed to be used in USM mode. 

I'm not completely up-to-date with what the OpenMP allocator traits can
de/prescribe (can they have an effect to stack allocations without
explicit allocate directive?). But from my perspective, compiler and
runtime should support two modes:

- completely rely on hardware support for USM, but error out at runtime,
if the runtime determines that hardware support is not available during
execution. Would it be possible to encode this into the sm-specific
runtime library?

- rely on the use of an OpenMP allocator which uses managed memory. For
compilation units with require USM, the compiler must use __kmpc_alloc
for all stack variables, where it is not possible prove that they will
not need managed memory, e.g., if they can escape to a function
potentially spawing a target region.

- Joachim

FYI: I also posted a related question on this topic at the omp-lang
list, asking for clarification on the expected behavior, if USM cannot
be guaranteed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20210302/dc1a2ddc/attachment.sig>


More information about the Openmp-dev mailing list