<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><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><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 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 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 href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a 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>