<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2017, at 9:41 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 01/13/2017 12:29 AM, Mehdi Amini
wrote:<br class="">
</div>
<blockquote cite="mid:5ADA0551-E374-48A7-8311-005E3AA947E4@apple.com" type="cite" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jan 12, 2017, at 5:02 PM, Hal Finkel <<a moz-do-not-send="true" href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:</div>
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class="">On 01/12/2017 06:20 PM, Reid Kleckner via
llvm-dev wrote:</p>
<blockquote cite="mid:CACs=tyKWmdPAQGJkJdrF9xdov-TnV02ofpPURjMGo7rwo28V8w@mail.gmail.com" type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Jan 11, 2017 at
8:13 PM, Mehdi Amini <span dir="ltr" class=""><<a moz-do-not-send="true" href="mailto:mehdi.amini@apple.com" target="_blank" class="">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" class="">
<div class="">
<div class="">Can you elaborate why? I’m
curious.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class="">
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 class=""><br class="">
</div>
<div class="">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 class="">
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 class=""></div></div></blockquote><div><br class=""></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 class=""></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><br class=""></div><div><br class=""></div><div>— </div><div>Mehdi</div></div></body></html>