<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 Feb 1, 2017, at 9:34 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 02/01/2017 01:29 AM, Mehdi Amini via
llvm-dev wrote:<br class="">
</div>
<blockquote cite="mid:48F1BD6C-7DC7-4B56-B0B4-F2E2292C3B40@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 31, 2017, at 10:59 PM, Tian, Xinmin <<a moz-do-not-send="true" href="mailto:xinmin.tian@intel.com" class="">xinmin.tian@intel.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="WordSection1" style="page: WordSection1;
font-family: Helvetica; font-size: 12px; font-style:
normal; font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent:
0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><a moz-do-not-send="true" name="_MailEndCompose" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></a></div>
<div class="">
<div style="border-style: solid none none;
border-top-width: 1pt; border-top-color: rgb(225, 225,
225); padding: 3pt 0in 0in;" class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><b class=""><span style="font-size: 11pt;
font-family: Calibri, sans-serif;" class="">From:</span></b><span style="font-size: 11pt; font-family: Calibri,
sans-serif;" class=""><span class="Apple-converted-space"> </span><a moz-do-not-send="true" href="mailto:mehdi.amini@apple.com" style="color: purple; text-decoration:
underline;" class="">mehdi.amini@apple.com</a><span class="Apple-converted-space"> </span>[<a moz-do-not-send="true" href="mailto:mehdi.amini@apple.com" style="color: purple; text-decoration:
underline;" class="">mailto:mehdi.amini@apple.com</a>]<span class="Apple-converted-space"> </span><br class="">
<b class="">Sent:</b><span class="Apple-converted-space"> </span>Tuesday,
January 31, 2017 9:03 PM<br class="">
<b class="">To:</b><span class="Apple-converted-space"> </span>Tian,
Xinmin <<a moz-do-not-send="true" href="mailto:xinmin.tian@intel.com" style="color: purple; text-decoration:
underline;" class="">xinmin.tian@intel.com</a>><br class="">
<b class="">Cc:</b><span class="Apple-converted-space"> </span>Sanjoy Das
<<a moz-do-not-send="true" href="mailto:sanjoy@playingwithpointers.com" style="color: purple; text-decoration:
underline;" class="">sanjoy@playingwithpointers.com</a>>;
Adve, Vikram Sadanand <<a moz-do-not-send="true" href="mailto:vadve@illinois.edu" style="color:
purple; text-decoration: underline;" class="">vadve@illinois.edu</a>>;<span class="Apple-converted-space"> </span><a moz-do-not-send="true" href="mailto:llvm-dev@lists.llvm.org" style="color: purple; text-decoration:
underline;" class="">llvm-dev@lists.llvm.org</a>;<span class="Apple-converted-space"> </span><a moz-do-not-send="true" href="mailto:llvm-dev-request@lists.llvm.org" style="color: purple; text-decoration:
underline;" class="">llvm-dev-request@lists.llvm.org</a><br class="">
<b class="">Subject:</b><span class="Apple-converted-space"> </span>Re:
[llvm-dev] [RFC] IR-level Region Annotations<o:p class=""></o:p></span></div>
</div>
</div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div>
<div class="">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;" class="">On Jan 31, 2017, at 7:53 PM, Tian, Xinmin
<<a moz-do-not-send="true" href="mailto:xinmin.tian@intel.com" style="color: purple; text-decoration:
underline;" class="">xinmin.tian@intel.com</a>>
wrote:<o:p class=""></o:p></div>
</div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div>
<div class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size:
12pt; font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt;
font-family: Calibri, sans-serif; color:
rgb(31, 73, 125);" class="">In this case,
inliner is educated to add all local variables
to the tag of enclosing parallel region, if
there is enclosing parallel region. </span><o:p class=""></o:p></div>
</div>
</div>
</blockquote>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="color: rgb(31, 73, 125);" class="">S</span>o
isn’t it a good example that shows that your
intrinsic *cannot* be opaque and that IR passes need
to be modified to handle not only the IR-region
intrinsic but also the specific semantic of the tag?<span style="color: rgb(31, 73, 125);" class=""><o:p class=""></o:p></span></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class="">[XT]
I thought we said a number of times, there are
small changes to be made. I quoted a ball park #
2000 LOC vs. 6000 LOC w.r.t changes, in one of
early emails.</span></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">This didn’t mean that the changes were meant specifically
for OpenMP. My understanding was that this proposal is for a
generic "IR-level Region Annotations” mechanism, and that’s
what the changes were for. Now it ends up being “let’s support
OpenMP semantic without adding openmp in the intrinsic names”.</div>
</div>
</blockquote>
<br class="">
The point here is to abstract the properties about which other
passes might need to know by using a set of generic intrinsics. </div></div></blockquote><div><br class=""></div><div>The fact is that I’m still not sure what these properties are, which is exactly why I’m asking for a LangRef patch.</div><div>If it has been explained in thread, then sorry I missed it, and I’d appreciate a pointer to the right post.</div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">The
fact that you can't hoist allocas past one of these intrinsics, is
nowhere close to saying that the individual optimization passes need
to know anything about OpenMP, parallelism, etc. Regardless of how
many LOC are in Intel's prototype, we're obviously aiming for
minimal impact on the current upstream infrastructure.<br class="">
<br class="">
<blockquote cite="mid:48F1BD6C-7DC7-4B56-B0B4-F2E2292C3B40@apple.com" type="cite" class="">
<div class="">
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<div class="WordSection1" style="page: WordSection1;
font-family: Helvetica; font-size: 12px; font-style: normal;
font-variant-caps: normal; font-weight: normal;
letter-spacing: normal; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; word-spacing:
0px; -webkit-text-stroke-width: 0px;">
<div class="">
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""></o:p></span></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class="">It
seems to me that this contradicts the claim that the
“tag” specific semantic does not need to be handled by
the optimizer and that the intrinsic can integrate
seamlessly in LLVM, which invalidates the approach (of
a generic intrinsic) entirely IMO.<o:p class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></div>
</div>
<div class="">
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class="">Maybe
you never intended to claim this, but this is a hidden
cost in the original RFC, and I suspect this cost has
to be carefully evaluated. At this point I’m not sure
it is worth discussing anything further without seeing
a proper LangRef update.<o:p class=""></o:p></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in 0in 0.0001pt; font-size: 12pt;
font-family: 'Times New Roman', serif;" class=""><span style="font-size: 11pt; font-family: Calibri,
sans-serif; color: rgb(31, 73, 125);" class="">[XT]
All we said is to minimize cost when it is possible.
The intrinsic functions is a generic for
representing a directive and region, such as
prefecth, unroll, omp, …. Each instance of them
will have their semantics which will be in following
up RFCs</span></div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">At this point I don’t see any advantage in having a
“generic intrinsic" that has an opaque tag since all the
semantic is in the tag anyway. I’d have to see what is really
“generic” in the handling of it...</div>
</div>
</blockquote>
<br class="">
This is completely opposite to the point. The semantics relevant to
the rest of the optimization pipeline should be in the intrinsics
themselves. I've yet to see anything to suggest that we can't do
that.<br class=""></div></div></blockquote><div><br class=""></div><div>I’ve yet to see anything that suggest we can :)</div><div><br class=""></div><div>How will it be expressed that we’re not allowed to be able to hoist an alloca? How are other constraints gonna be expressed?</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
<blockquote cite="mid:48F1BD6C-7DC7-4B56-B0B4-F2E2292C3B40@apple.com" type="cite" class="">
<div class="">
<div class=""><br class="">
</div>
<div class="">Reid identified this very early in the thread (he is a lot
more perspicacious than I am) here: <a moz-do-not-send="true" href="http://lists.llvm.org/pipermail/llvm-dev/2017-January/108914.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2017-January/108914.html</a></div>
</div>
</blockquote>
<br class="">
There are multiple levels here:<br class="">
a) Semantics relevant to the rest of the pipeline<br class="">
b) Semantics relevant to parallelism-specific optimizations (e.g.
redundant barrier removal)<br class="">
c) Semantics relevant to specific programming model / extension
(OpenMP, OpenACC, C++ parallel algorithms, whatever)<br class="">
<br class="">
We'd like to separate these three levels, and I believe the proposed
scheme allows us to do that. Obviously, this assumes that we can
indeed have a small set of intrinsics that satisfy the needs of (a).
Furthermore, if we're going to use intrinsics, we need to decide
whether all of the relevant semantics are reasonable to encode in
intrinsics (e.g. it is reasonable to have an intrinsic past which
you can't hoist an alloca, or would that need to be an instruction,
etc.)<br class=""></div></div></blockquote><div><br class=""></div>I agree with all that, and for now I’m only worried about a), which is why I asked for a LangRef update because I don’t feel I read a proper explanation there. </div><div> <br class=""><div><br class=""></div></div>— <div class="">Mehdi</div><div class=""><br class=""></div></body></html>