[PATCH] Add AnyReg calling convention support for patchpoint intrinsic.

[Andrew Trick]

On Oct 28, 2013, at 5:09 PM, Eric Christopher <echristo at gmail.com> wrote:

> 
> 
> 
> On Mon, Oct 28, 2013 at 4:46 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> 
> On Oct 28, 2013, at 4:10 PM, Eric Christopher <echristo at gmail.com> wrote:
> 
> >
> >  Few comments:
> >
> >  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.

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.

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.

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.

> >
> >  b) There's no fast-isel support for this? Pretty surprised given JIT.
> 
> 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.
> 
> 
> 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.

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.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131028/a58e09c3/attachment.html>