<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 6/24/20 7:26 PM, Jeff Hammond wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGKz=u+y2PH3UM7HPJK-6s9n=UwecHfxG1_AKJ29uH+hhBwa2g@mail.gmail.com">
<div dir="ltr">
<div>Does OpenMP 5 allow calling symbols that are not
omp-declare-target?</div>
</div>
</blockquote>
<p><br>
</p>
<p>I'm not sure this is relevant because the implementation gets to
provide such symbols (and we depend on it doing so in other cases,
such as for math.h functions).<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAGKz=u+y2PH3UM7HPJK-6s9n=UwecHfxG1_AKJ29uH+hhBwa2g@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>In any case, I am concerned about malloc interception,
having seen that break many times in the past. OpenMP isn't
the only thing that wants to intercept malloc, and nested
interception may not be stable.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Why are you bringing up interception? I did not think that
anything in this message implied intercepting malloc.</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAGKz=u+y2PH3UM7HPJK-6s9n=UwecHfxG1_AKJ29uH+hhBwa2g@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Why is omp_alloc not the best option here? That avoids
essentially all of the issues I can think of.</div>
<div><br>
</div>
<div>Jeff</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 24, 2020 at
11:12 AM Hal Finkel via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" moz-do-not-send="true">openmp-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi, Jon,</p>
<p>This is a great question. <br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>"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.</p>
<p>Thanks again,</p>
<p>Hal<br>
</p>
<div>On 6/24/20 6:40 AM, Jon Chesterfield via Openmp-dev
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">Hello OpenMP,
<div dir="auto"><br>
</div>
<div dir="auto">Our language spec seems fairly light
on what it means to call malloc from a target
region.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I can think of a few interpretations:</div>
<div dir="auto">- 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.</div>
<div dir="auto">- One heap per device + one for host.
Each independent, pointers only valid on the thing
that called malloc.</div>
<div dir="auto">- One heap per target offload region,
inaccessible from host.</div>
<div dir="auto">- Some other granularity.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Generally gets faster as the
restrictions increase.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thanks,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Jon</div>
<div dir="auto"><br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Openmp-dev mailing list
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">Openmp-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a>
</pre>
</blockquote>
<pre cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>
_______________________________________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@lists.llvm.org" target="_blank" moz-do-not-send="true">Openmp-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com" target="_blank" moz-do-not-send="true">jeff.science@gmail.com</a><br>
<a href="http://jeffhammond.github.io/" target="_blank" moz-do-not-send="true">http://jeffhammond.github.io/</a></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>