<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 8:41 PM, Jeff Hammond wrote:<br>
</div>
<blockquote type="cite" cite="mid:104B4FD7-5530-43D1-91AD-D63710B22D5D@gmail.com">
<div dir="ltr"><br>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On Jun 24, 2020, at 6:32 PM, Hal Finkel
<a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov"><hfinkel@anl.gov></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<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).</p>
</div>
</blockquote>
<div>Is LLVM OpenMP going to assume one and only C RTL? Which one?</div>
<div><br>
</div>
<div>Supporting glibc, musl, as well as third party allocators
like tbbmalloc, jemalloc, tcmalloc, etc. may be broken by such
assumptions. </div>
<blockquote type="cite">
<div dir="ltr">
<p> </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>
</div>
</blockquote>
<div>I was responding to the previous email where it said “<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);
-webkit-text-size-adjust: auto; background-color: rgb(255,
255, 255);">Might mean intercepting host libc.“</span></div>
</blockquote>
<p><br>
</p>
<p>Ah, thanks. I think we should support this only in cases where we
can do so without interception. On Linux + HMM, for example. As
you point out, it's hard to do this in a robust way otherwise.</p>
<p> -Hal<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:104B4FD7-5530-43D1-91AD-D63710B22D5D@gmail.com">
<div><br>
</div>
Jeff<br>
<blockquote type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>