<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 20, 2017 at 12:52 PM, Mehdi Amini via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 20, 2017, at 6:59 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:</div><br class="m_3683543841662625865Apple-interchange-newline"><div>
<div bgcolor="#FFFFFF" text="#000000"><p>On 01/13/2017 12:11 PM, Mehdi Amini wrote:<br>
</p>
<blockquote type="cite">
<br>
<div>
<blockquote type="cite">
<div>On Jan 13, 2017, at 9:41 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:</div>
<br class="m_3683543841662625865Apple-interchange-newline">
<div>
<div bgcolor="#FFFFFF" text="#000000"><p><br>
</p>
<div class="m_3683543841662625865moz-cite-prefix">On 01/13/2017 12:29 AM, Mehdi
Amini wrote:<br>
</div>
<blockquote type="cite"> <br>
<div>
<blockquote type="cite">
<div>On Jan 12, 2017, at 5:02 PM, Hal
Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>
wrote:</div>
<div>
<div bgcolor="#FFFFFF" text="#000000"><p>On 01/12/2017 06:20 PM, Reid
Kleckner via llvm-dev wrote:</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Jan 11,
2017 at 8:13 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span>
wrote:
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>
<div>Can you elaborate
why? I’m curious.</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The con of proposal c was
that many passes would need to learn
about many region intrinsics. With
tokens, you only need to teach all
passes about tokens, which they should
already know about because WinEH and
other things use them.</div>
<div><br>
</div>
<div>With tokens, we can add as
many region-introducing intrinsics as
makes sense without any additional
cost to the middle end. We don't need
to make one omnibus region intrinsic
set that describes every parallel loop
annotation scheme supported by LLVM.
Instead we would factor things
according to other software design
considerations.</div>
</div>
</div>
</div>
</blockquote>
<br>
I think that, unless we allow frontends to add
their own intrinsics without recompiling LLVM,
this severely restricts the usefulness of this
feature.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I’m not convinced that “building a
frontend without recompiling LLVM while injecting
custom passes” is a strong compelling use-case, i.e.
can you explain why requiring such
use-case/frontends to rebuild LLVM is so limiting?</div>
</div>
</blockquote>
<br>
I don't understand your viewpoint. Many frontends either
compose their own pass pipelines or use the existing
extension-point mechanism. Some frontends, Chapel for
example, can insert code using custom address spaces and
then insert passes later to turn accesses using pointers
to those address spaces into runtime calls. This is the
kind of design we'd like to support, without forcing
frontends to use custom versions of LLVM, but with
annotated regions instead of just with address spaces.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think we’re talking about two different things here: you
mentioned originally “without recompiling LLVM”, which I don’t
see as major blocker, while now you’re now clarifying I think
that you’re more concerned about putting a requirement on a
*custom* LLVM, as in “it wouldn’t work with the source from a
vanilla upstream LLVM”, which I agree is a different story.</div>
<div><br>
</div>
<div>That said, it extends the point from the other email (in
parallel) about the semantics of the intrinsics: while your
solution allows these frontend to reuse the intrinsics, it
means that upstream optimization have to consider such
intrinsics as optimization barrier because their semantic is
unknown.</div>
</div>
</blockquote>
<br>
I see no reason why this needs to be true (at least so long as
you're willing to accept a certain amount of "as if" parallelism).
</div></div></blockquote><div><br></div></span><div>Sorry, I didn’t quite get that?</div><span class=""><br><blockquote type="cite"><div><div bgcolor="#FFFFFF" text="#000000">Moreover, if it is true, then we'll lose the benefits of, for
example, being able to hoist scalar loads out of parallel loops. We
might need to include dependencies on "inaccessible memory", so
cover natural runtime dependencies by default (this can be refined
with custom AA logic), but that is not a complete code-motion
barrier. Memory being explicitly managed will end up as arguments to
the region intrinsics, so we'll automatically get more-fine-grained
information.<br></div></div></blockquote><div><br></div></span><div>Sanjoy gave an example of the kind of optimization that can break the semantic: <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-January/109302.html" target="_blank">http://lists.llvm.<wbr>org/pipermail/llvm-dev/2017-<wbr>January/109302.html</a> ; I haven’t yet seen an explanation about how this is addressed?</div></div></div></blockquote><div>If you were asking how this is addressed in the current clang/openmp, the code in the whole parallel region is outlined into a new function by frontend and parallel fork-join is transformed to a runtime call (kmpc_fork_call) that takes as input a pointer to the outlined function. so procedure-based optimization would not perform those optimization Sanjoy listed.</div><div><br></div><div>Yonghong</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>I’m not sure how you imagine going around the optimization barrier that goes with “this intrinsic has an unknown semantic that can impact the control flow of the program implicitly”, unless it acts as a “hint” only (but I don’t believe it is the direction?).</div><div><br></div><div>— </div><div>Mehdi</div></div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>