<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/22/13 10:48 PM, Andrew Trick
wrote:<br>
</div>
<blockquote
cite="mid:FE120C63-E4BE-433C-A416-2B75DC3FC566@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>I'll respond to a few questions below. I'll start a new
thread for GC discussion.</div>
</blockquote>
Good idea. Thanks.<br>
<blockquote
cite="mid:FE120C63-E4BE-433C-A416-2B75DC3FC566@apple.com"
type="cite">
<div><br>
</div>
<div>
<div>On Oct 22, 2013, at 6:24 PM, Philip R <<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:9D0E9F3E-E55E-477E-BBF0-E6E3C668DE7A@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;">Now
with regard to patching. I think llvm.patchpoint is
generally useful for any type of patching I can imagine.
It does look like a call site in IR, and it’s nice to be
able to leverage calling conventions to inform the
location of arguments.</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;">Agreed. My concern is mostly
about naming and documentation of intended usages.
Speaking as someone who's likely to be using this in the
very near future, I'd like to make sure I understand how
you intend it to be used. The last thing I want to do is
misconstrue your intent and become reliant on a quirk of
the implementation you later want to change.</span><br
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;">
</div>
</blockquote>
<div><br>
</div>
<div>I don't think the intrinsic names will be able to capture
their semantics. I think that's why we need documentation,
which I've been working on: <a moz-do-not-send="true"
href="http://llvm-reviews.chandlerc.com/D1981">http://llvm-reviews.chandlerc.com/D1981</a>.</div>
<div><br>
</div>
<div>
<div>For example, the "stackmap" intrinsic isn't really a
stack map, it's something that allows generation of a stack
map in which the entries don't actually need to be on the
stack... confusing, but still a good name I think.</div>
</div>
</div>
</blockquote>
"stack map" is also a fairly well understood term in the GC/compiler
world. It's better to stick with well known terminology where
possible. <br>
<br>
As for naming vs documentation, I tend to believe that naming should
be as descriptive as is reasonable. Having said that, we're well
past the point of adding value with this discussion. Please update
the documentation to reflect some of the clarifications on usage
that have come up here and let's move on. <br>
<blockquote
cite="mid:FE120C63-E4BE-433C-A416-2B75DC3FC566@apple.com"
type="cite">
<div>
<div><br>
</div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:9D0E9F3E-E55E-477E-BBF0-E6E3C668DE7A@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;">But
the patchpoint does not have to be a call after patching,
and you can specify zero arguments to avoid using a
calling convention.</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;">Er, not quite true. Your
calling convention also influences what registers stay
live across the call. But in general, I see your point.</span><br
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;">
</div>
</blockquote>
<div><br>
</div>
<div>You get around that by defining a new calling convention.
Each patchpoint intrinsic call can be marked with a different
calling convention if you choose. For example, we'll be adding
a dynamic calling convention called AnyRegCC. You can use that
to effectively specify the number of arguments that you want
to force into registers. The stack map will tell you which
registers were used for arguments. The "call" will preserves
most registers, but clobbers one register (on x86) for use
within the code.</div>
</div>
</blockquote>
Nice trick. I'll have to remember that. <br>
<blockquote
cite="mid:FE120C63-E4BE-433C-A416-2B75DC3FC566@apple.com"
type="cite">
<div>
<div><br>
</div>
<div>Another potential extension is to add an entry to the
stackmap marking physical registers that are actually in-use
across the stack map or patch point.</div>
<div><br>
</div>
<div>It helps me to think of llvm.patchpoint as a replacement
for any situation where a JIT would have otherwise needed
inline asm to generate the desired code sequence.</div>
<div><br>
</div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"><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;">(Again, this is touching an
area of LLVM I'm not particularly familiar with.)</span><br
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;">
<blockquote
cite="mid:9D0E9F3E-E55E-477E-BBF0-E6E3C668DE7A@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;">In
fact, we only currently emit a call out of convenience. We
could splat nops in place and assume the runtime will
immediately find and patch all occurrences before the code
executes. In the future we may want to handle NULL call
target, bypass call emission, and allow the reserved bytes
to be less than that required to emit a call.</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;">If you were to do that, how
would the implementation be different then the new
stackmap intrinsic? Does that difference imply a
clarification in intended usage or naming?</span><br
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;">
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
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. <br>
<blockquote
cite="mid:FE120C63-E4BE-433C-A416-2B75DC3FC566@apple.com"
type="cite">
<div>
<div><br>
</div>
<div>We could have defined different intrinsics for all
variations of use cases, but I think two is the right number:</div>
<div><br>
</div>
<div>- Use llvm.stackmap if you just want a stack map. No code
will be emitted. There is no calling convention. If the
runtime patches the code here, it will be destructive.</div>
<div><br>
</div>
<div>- Use llvm.patchpoint if you want to reserve space for
patching the code. When you do that, you can optionally
specify a number of arguments that will follow a specified
calling convention. You also get a stack map here because it
can be useful to fuse the stack map to the point point
location. After all, the runtime needs to know where to patch.</div>
</div>
</blockquote>
This summary is really helpful. <br>
<br>
This summary and the other points you've made in our discussion is
exactly what should be in the documentation. It provides the
thought process behind their design, and the intended usage
scenarios. Can you add a section with this meta information? <br>
<br>
Yours,<br>
Philip<br>
<br>
p.s. Thank you both for taking the time to hash this through. <br>
</body>
</html>