<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 9/30/19 3:49 PM, Lingda Li via Openmp-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABGk1BODVJpKUX7sO1DzyuuNUV8wt92JdTNOzdYjt8T9wqvzsQ@mail.gmail.com">
<div dir="ltr">Hi,
<div><br>
</div>
<div>I would like to bring your attention to the choice of 2 proposals for the declare mapper runtime interface:</div>
<div><br>
</div>
<div>1. The current design which creates new runtime functions for declare mappers. For example, right now we have `__tgt_target_teams(...)` which corresponds to the runtime interface for `omp target teams`. Now we add `__tgt_target_teams_mapper(..., void **mappers)`
to replace it.</div>
<div><br>
</div>
<div>As a result, the old interfaces will be deprecated, but they need to be kept there for backward compatibility. I think this scheme is clear and has no hidden problems. The down side is it will create more OpenMP runtime interfaces. The patches for this
scheme can be found at <a href="https://reviews.llvm.org/D67833" moz-do-not-send="true">https://reviews.llvm.org/D67833</a> and <a href="https://reviews.llvm.org/D68100" moz-do-not-send="true">https://reviews.llvm.org/D68100</a>.</div>
<div><br>
</div>
<div>2. Introduce a function `__tgt_push_mappers`, which should be called before every target function call (e.g., `__tgt_target_teams`) to pass the mapper argument for that function. The call of `__tgt_push_mappers` is implicitly bonded with the actual target
call.</div>
<div><br>
</div>
<div>This scheme will introduce less runtime interfaces. Its problem is the implementation is not straightforward and needs to take extra precautions. For example, each OpenMP task should have a separate mapper storage, to prevent a target region from reading
the mapper written by another task.</div>
<div><br>
</div>
<div>Your option about which one is better will be greatly appreciated.</div>
</div>
</blockquote>
<p><br>
</p>
<p>I prefer option 1. I don't like the idea of introducing extra mandatory state in the library simply to avoid adding a new runtime call with additional parameters. My experience is that this kind of extra state is more likely to be a source of bugs than the
extra parameters of a new function, plus the extra function-call overhead and memory traffic is likely more expensive than the extra parameter passing. We need to extend the API either way.</p>
<p>Furthermore, I suspect that breaking of the runtime call into several stateful calls will make the calls more difficult to analyze within the optimizer. Johannes, do you agree?</p>
<p>I realize that we've done this kind of thing in the past - and similar things exist in the CUDA runtime interface, etc. - but my experience with this kind of API extension has been largely negative.<br>
</p>
<p> -Hal</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CABGk1BODVJpKUX7sO1DzyuuNUV8wt92JdTNOzdYjt8T9wqvzsQ@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Thanks,</div>
<div>Lingda Li</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openmp-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openmp-dev@lists.llvm.org">Openmp-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>