<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Oct 28, 2013, at 5:09 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 28, 2013 at 4:46 PM, Filip Pizlo <span dir="ltr"><<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div class="im"><br>
On Oct 28, 2013, at 4:10 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
<br>
><br>
> Few comments:<br>
><br>
> a) would this be better off by defining away the problem and having the stack map/patch point intrinsics be not-calls? If you don't care where things are the only thing you care about is that certain registers are saved and restored and you might be able to mark them as clobberable instead.<br></div></blockquote></div></div></div></blockquote><div><br></div><div>One of the reasons that patchpoints are calls is that we want to allow the frontend to be able to specify the calling convention. WebKit will use different calling conventions for different types of patchpoints.</div><div><br></div><div>AnyRegCC is just a special case for when we want certain intrinsic “arguments” to be in registers but don’t care which registers. We could just use an arbitrary calling convention and claim there are zero (fixed) arguments. But those non-argument intrinsic operands would be spillable. The client might want to emit patched code that reads those registers without implementing different versions of the patching to handle all the variations of spilled or in-register arguments, and reserving lots of space for that.</div><div><br></div><div>Clobbering is also something that would be nice to have. Unfortunately, just adding a callee-save regmask to the calling convention won’t work, because the argument registers don’t interfere with the regmask. i.e. it’s legal to use clobbered registers for call arguments. That won’t work if we want to use both the clobbered register and argument register in the patched code sequence. This feature was messy enough to split into a separate patch, which hasn’t been posted yet.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div class="im">><br>
> b) There's no fast-isel support for this? Pretty surprised given JIT.<br>
<br>
</div>We aren’t currently planning on using fast-isel. We’re not using LLVM because we want a fast code generator. We’re using it because we want to generate fast code.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br></div><div>That's up to you, of course, but this is a general LLVM feature and it seems useful to have fast-isel support if it's reasonably trivial.</div></div></div></div></blockquote><div><br></div>Good point. If it’s reasonably trivial then it should not be hard for anyone to add when they need it. I don’t see why that would hold up the rest of the functionality.</div><div><br></div><div>-Andy</div><br></body></html>