<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 23, 2013, at 7:26 PM, Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/23/13 5:38 PM, Andrew Trick
wrote:<br>
</div>
<blockquote cite="mid:1DB87D5C-C4BA-49AD-9D99-1A30990745CA@apple.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Oct 23, 2013, at 5:27 PM, Philip Reames <<a moz-do-not-send="true" href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote cite="mid:FE120C63-E4BE-433C-A416-2B75DC3FC566@apple.com" type="cite" style="font-family: Helvetica; font-size:
12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The
implementation of the two intrinsics is actually very
similar. In this case, the difference would be that
llvm.stackmap does not reserve space for patching, while
llvm.patchpoint does.</blockquote>
<span style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); float: none;
display: inline !important;">I'm slightly confused by this
given that stackmap takes an argument indicating the
number of nops to emit as well, but it's not worth
debating this any more. Let's move on. We can revisit
this once I'm actually using the new intrinsics and can
provide real concrete feedback. <span class="Apple-converted-space"> </span></span></div>
</blockquote>
</div>
<div><br>
</div>
I want this to be clear when we expose the intrinsics to other
developers. I’ve been making an effort to improve the docs: <a moz-do-not-send="true" href="http://llvm-reviews.chandlerc.com/D1981">http://llvm-reviews.chandlerc.com/D1981</a>.
Please let me know where clarification is needed</blockquote>
I responded in the review. The only big thing that might be worth
discussion here is the "full resume" semantics which are mentioned
at the very end. This seemed to disagree with our previous
discussion. Let me know if you're either a) unclear at what I was
getting at or b) believe the "full resume" semantics were a key part
of the intrinsic. In either case, we should probably hash it out
here. <br></div></blockquote></div><br><div>Thanks for the review. I'll respond to each of your comments there.</div><div><br></div><div>There's one important thing I'm not getting across. llvm.stackmap is not primarily intended for patching. As an additional feature, llvm.stackmap can specify the size of its shadow, but does not need to generate nops in its shadow. The shadow can contain arbitrary code from the same function. The only purpose of the shadow is to allow destructive patching. Destructive means that other that some arbitrary code may be overwritten. I think the only use for this is to invalidate compiled code in a way that allows the runtime to recover. That just happens to be a very important use. Note that if we didn't specify a shadow, the runtime would have a hard time knowing how to patch without potentially clobbering something outside the current function.</div><div><br></div><div>-Andy</div></body></html>