<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/22/13 3:08 PM, Filip Pizlo wrote:<br>
</div>
<blockquote
cite="mid:059111CB-A2DB-4420-9907-A94E90415A61@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Oct 22, 2013, at 1:48 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 style="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;">On 10/22/13 10:34 AM, Filip Pizlo wrote:<br>
<blockquote type="cite">On Oct 22, 2013, at 9:53 AM, Philip
R <<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>>
wrote:<br>
<br>
<blockquote type="cite">On 10/17/13 10:39 PM, Andrew Trick
wrote:<br>
<blockquote type="cite">This is a proposal for adding
Stackmaps and Patchpoints to LLVM. The<br>
first client of these features is the JavaScript
compiler within the<br>
open source WebKit project.<br>
<br>
</blockquote>
I have a couple of comments on your proposal. None of
these are major enough to prevent submission.<br>
<br>
- As others have said, I'd prefer an experimental
namespace rather than a webkit namespace. (minor)<br>
- Unless I am misreading your proposal, your proposed
StackMap intrinsic duplicates existing functionality
already in llvm. In particular, much of the StackMap
construction seems similar to the Safepoint mechanism
used by the in-tree GC support. (See
CodeGen/GCStrategy.cpp and CodeGen/GCMetadata.cpp).
Have you examined these mechanisms to see if you can
share implementations?<br>
- To my knowledge, there is nothing that prevents an
LLVM optimization pass from manufacturing new pointers
which point inside an existing data structure. (e.g. an
interior pointer to an array when blocking a loop) Does
your StackMap mechanism need to be able to
inspect/modify these manufactured temporaries? If so, I
don't see how you could generate an intrinsic which
would include this manufactured pointer in the live
variable list. Is there something I'm missing here?<br>
</blockquote>
These stackmaps have nothing to do with GC. Interior
pointers are a problem unique to precise copying
collectors.<br>
</blockquote>
I would argue that while the use of the stack maps might be
different, the mechanism is fairly similar.</div>
</blockquote>
<div><br>
</div>
<div>It's not at all similar. These stackmaps are only useful
for deoptimization, since the only way to make use of the live
state information is to patch the stackmap with a jump to a
deoptimization off-ramp. You won't use these for a GC.</div>
<br>
<blockquote type="cite">
<div style="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 general, if the expected semantics are the same, a
shared implementation would be desirable. This is more a
suggestion for future refactoring than anything else.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I think that these stackmaps and GC stackmaps are fairly
different beasts. While it's possible to unify the two, this
isn't the intent here. In particular, you can use these
stackmaps for deoptimization without having to unwind the
stack.</div>
</div>
</blockquote>
I'm going to respond to Andrew Trick's followup for this portion. <br>
<blockquote
cite="mid:059111CB-A2DB-4420-9907-A94E90415A61@apple.com"
type="cite">
<div><br>
<blockquote type="cite">
<div style="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;"><br>
I agree that interior pointers are primarily a problem for
relocating collectors. (Though I disagree with the
characterization of it being *uniquely* a problem for such
collectors.) Since I was unaware of what you're using your
stackmap mechanism for, I wanted to ask. Sounds like this
is not an intended use case for you.<br>
<blockquote type="cite"><br>
In particular, the stackmaps in this proposal are likely
to be used for capturing only a select subset of state and
that subset may fail to include all possible GC roots.
These stackmaps are meant to be used for reconstructing
state-in-bytecode (where bytecode = whatever your baseline
execution engine is, could be an AST) for performing a
deoptimization, if LLVM was used for compiling code that
had some type/value/behavior speculations.<br>
</blockquote>
Thanks for the clarification. This is definitely a useful
mechanism. Thank you for contributing it back.<br>
<blockquote type="cite"><br>
<blockquote type="cite">- Your patchpoint mechanism
appears to be one very specialized use of a patchable
location. Would you mind renaming it to something like
patchablecall to reflect this specialization?<br>
</blockquote>
The top use case will be heap access dispatch inline
cache, which is not a call.<br>
You can also use it to implement call inline caches, but
that's not the only thing you can use it for.<br>
</blockquote>
Er, possibly I'm misunderstanding you. To me, a inline call
cache is a mechanism to optimize a dynamic call by adding a
typecheck+directcall fastpath.</div>
</blockquote>
<div><br>
</div>
<div>Inline caches don't have to be calls. For example, in
JavaScript, the expression "o.f" is fully dynamic but usually
does not result in a call. The inline cache - and hence
patchpoint - for such an expression will not have a call in
the common case.</div>
<div><br>
</div>
<div>Similar things arise in other dynamic languages. You can
have inline caches for arithmetic. Or for array accesses. Or
for any other dynamic operation in your language.</div>
<br>
<blockquote type="cite">
<div style="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;"> (i.e. avoiding the dynamic dispatch logic in the
common case) I'm assuming this what you mean with the term
"call inline cache", but I have never heard of a "heap
access dispatch inline cache". I've done a google search
and didn't find a definition. Could you point me to a
reference or provide a brief explanation?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Every JavaScript engine does it, and usually the term
"inline cache" in the context of JS engines implies
dispatching on the shape of the object in order to find the
offset at which a field is located, rather than dispatching on
the class of an object to determine what method to call.</div>
</div>
</blockquote>
Thank you for the clarification. I am familiar with the patching
optimizations performed for property access, but had not been aware
of the modified usage of the term "inline cache". I was also
unaware of the term "heap access dispatch inline cache". I believe
I now understand your intent. <br>
<br>
Taking a step back in the conversation, my original question was
about the naming of the patchpoint intrinsic. I am now convinced
that you could use your patchpoint intrinsic for a number of
different inline caching schemes (method dispatch, property access,
etc..). Given that, my concern about naming is diminished, but not
completely eliminated. I don't really have a suggestion for a
better name, but given that a "stackmap" intrinsic can be patched,
the "patchpoint" intrinsic name doesn't seem particularly
descriptive. To put it another way, how are the stackmap and
patchpoint intrinsics different? Can this difference be encoded in
a descriptive name for one or the other?<br>
<br>
As a secondary point, it would be good to update the proposed
documentation with a brief description of the intended usage (i.e.
inline caching). This might prevent a future developer from being
confused on the same issues. <br>
<br>
Yours,<br>
Philip<br>
<br>
</body>
</html>