<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 07/12/2015 02:12 PM, Marius Wachtler
wrote:<br>
</div>
<blockquote
cite="mid:CANycJ-D7wf3J9tQxpYLGSAPUgbrXvr_3xtFwj5qLwxvBLC809Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>I submitted several weeks ago a patch D9176 to extend
stackmaps to support symbolic constants.</div>
<div>I think this is a good time to clean up this patch by
proposing to add another stackmap location type for symbolic
constants to the new v2 StackMap format.</div>
</div>
</blockquote>
Yep, great timing. <br>
<blockquote
cite="mid:CANycJ-D7wf3J9tQxpYLGSAPUgbrXvr_3xtFwj5qLwxvBLC809Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>The idea is that this new type behaves like the
ConstantIndex type with the only difference that the constant
value specified at the index will be zero when stored on disk
and will get filled in by the runtime linker with the actual
value of the symbol (returned value from
RTDyldMemoryManager::getSymbolAddress).</div>
<div><br>
</div>
<div>Please let my know what you think.</div>
<div><br>
</div>
<div>My use case is (this is a copy of reply I just send to the
review request):</div>
<div><br>
</div>
<div>We (Pyston project) use patchpoints to implement inline
caches and for deoptimization when using the LLVM tier.</div>
<div>For the deoptimization use case we add all variables to the
patchpoint live args which we need too continue the execution
in a lower generic tier (e.g. interpreter). A lot of our
generated IR values were direct inttoptr casts because we
often generate instances of our objects outside of LLVM. For
example we may generate instances of a python objects when we
setup the internal representation of a python function which
we then share between the interpreter and LLVM tier. That's
why we had a lot of inttoptr casts in our generated IR, there
are also additional args like pointers to the AST nodes which
we will need for deopt.</div>
<div><br>
</div>
<div>Deopimizations should happen only very rarely that means
that we don't want to actually load all the constants we
specified as live values inside the patchpoint into
registers/stack slots. Currently LLVM will put all arguments
which are constants inside the stackmap constant table in
order to not have to generate code in front of the patchpoint
to put all this constant values into register/stack slots.
This is exactly how I would expect the behavior to be and how
I need it.</div>
<div><br>
</div>
<div>But then I added a new feature: in order to speedup JITing
time if we encounter the same function on the next application
start I implemented an object cache for the LLVM generated
code. This means I need to be able to relocate all this
embedded pointers because the memory layout will not be the
same. I choose to solve this by emitting special unique symbol
name for all cases where I previously embedded the direct
pointer value. This symbol names are deterministic, on the
next startup when encountering the same function I can
directly load it from the object cache and just have to return
the real pointer values inside the
RTDyldMemoryManager::getSymbolAddress() overloaded function.</div>
<div><br>
</div>
<div>The problem I encountered and this patch tries to solve is
that LLVM will currently emit code which will load all this
symbolic constants into registers before the patchpoint. With
this patch we will stop emitting this machine instructions and
instead emit constant table entries inside the stackmap.</div>
<div> </div>
<div>Hope this helps understanding what I have done (even if my
english isn't good), I successfully use this solution now
since several weeks and it gave us a huge speedup.</div>
</div>
</blockquote>
Thanks for the context. The explanation made this make a lot more
sense to me than the original patch had. <br>
<br>
I'm generally in support of this feature being added subject to
normal code review. If nothing else, we should think about the
format requirements even if the implementation isn't quite in yet.
It's definitely something which would be good to support at some
point. <br>
<blockquote
cite="mid:CANycJ-D7wf3J9tQxpYLGSAPUgbrXvr_3xtFwj5qLwxvBLC809Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Jul 10, 2015 at 6:47 PM,
Juergen Ributzka <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:juergen@apple.com"
target="_blank">juergen@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Sounds good. I will add
that to the StackMap documentation when I update it for
v2.<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>—Juergen</div>
</font></span><span class="">
<div><br>
<div>
<blockquote type="cite">
<div>On Jul 10, 2015, at 9:40 AM, Hal Finkel <<a
moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>
wrote:</div>
<br>
<div><span
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">No,
but I've noticed that it is true in practice,
and so I think that we should say something
about it one way or another. Especially since,
in switching to a fixed-size record format,
binary searching now becomes relatively
easy/fast. Maybe it would be a useful
guarantee?</span><br
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Thanks
again,</span><br
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Hal</span></div>
</blockquote>
</div>
<br>
</div>
</span></div>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a moz-do-not-send="true" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>
<a moz-do-not-send="true"
href="http://llvm.cs.uiuc.edu" rel="noreferrer"
target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>