<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - jsc-tailcall: JavaScript functions should restore the stack pointer after a call"
href="https://bugs.webkit.org/show_bug.cgi?id=146846#c1">Comment # 1</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - jsc-tailcall: JavaScript functions should restore the stack pointer after a call"
href="https://bugs.webkit.org/show_bug.cgi?id=146846">bug 146846</a>
from <span class="vcard"><a class="email" href="mailto:basile_clement@apple.com" title="Basile Clement <basile_clement@apple.com>"> <span class="fn">Basile Clement</span></a>
</span></b>
<pre>Created <span class=""><a href="attachment.cgi?id=256709&action=diff" name="attach_256709" title="Patch using StackMap size">attachment 256709</a> <a href="attachment.cgi?id=256709&action=edit" title="Patch using StackMap size">[details]</a></span>
Patch using StackMap size
This uses the stackmap size from LLVM to restore the stack pointer to where it should be in the patchpoint. I am interested in hearing opinions on the following two points:
- We may want to adapt the default patchpoint size to accommodate the additional lea opcode.
- LLVM provides a stackmap/stackrestore intrinsic that we should be able to use. I am unsure what guarantees we would have with this; in particular, I fear LLVM spilling values onto the stack before the call but after saving the stack pointer, performing the call, then trying to restore those values using the stack pointer as it is supposed to be callee-save. I did not see this happen even when testing that approach with high register pressure (LLVM ends up using bp-based offsets for the spilling), but again, I am unsure how much we can rely on this. I believe messing up with the stack pointer in the patchpoint is better because it makes it completely transparent to LLVM.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>