[Openmp-dev] Malloc in target region

[Hal Finkel via Openmp-dev]

Hi, Jon,

This is a great question.

With reverse-offload support, and unified memory, we can support a model 
where memory allocation triggers reverse offload to the memory allocator 
on the host. In this mode, everything works as expected. We can, of 
course, do some static analysis and move allocations that don't escape 
to use some local allocation scheme, such as what we use without unified 
memory + reverse offload.

Without such support, I think that "One heap per device + one for host. 
Each independent, pointers only valid on the thing that called malloc." 
makes the most sense. This also, as far as I know, matches what's 
available in CUDA today.

"One heap per target offload region" doesn't make sense to me. One might 
clearly want to allocate in one target region, store the pointers in 
some data structure, and then access them in some other target region on 
the same device.

Thanks again,

Hal

On 6/24/20 6:40 AM, Jon Chesterfield via Openmp-dev wrote:
> Hello OpenMP,
>
> Our language spec seems fairly light on what it means to call malloc 
> from a target region.
>
> I can think of a few interpretations:
> - One heap per process. Malloc on target or host, free from either. 
> Writable from either, or some other device. Might mean intercepting 
> host libc. Convenient, slow.
> - One heap per device + one for host. Each independent, pointers only 
> valid on the thing that called malloc.
> - One heap per target offload region, inaccessible from host.
> - Some other granularity.
>
> Generally gets faster as the restrictions increase.
>
> Anyone willing to state / guess what they or their users would expect? 
> Bearing in mind that new is likely to call malloc and will gain the 
> same properties.
>
> Thanks,
>
> Jon
>
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200624/8b4b6d10/attachment.html>