<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 24, 2013, at 9:31 AM, 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 10:03 PM, Andrew Trick
wrote:<br>
</div>
<blockquote cite="mid:304D65E6-4BC5-4CBF-97B7-4F715447D7FA@apple.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Oct 23, 2013, at 7:26 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">
<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>
</blockquote>
So essentially you're using the shadow region to enable creating
either a nop sled which carries you down into deopt code or a forced
trap (i.e. patching with an instruction sequence which forces a trap
to a signal handler)? Ok, that sounds reasonable. You should spell
this out this example explicitly in the documentation. It's useful
for clarification purposes.<br></div></blockquote><div><br></div><div>The latest version of the documentation can be found here:</div><a href="http://llvm-reviews.chandlerc.com/D1981">http://llvm-reviews.chandlerc.com/D1981</a></div><div><br></div><div>-Andy</div><br></body></html>