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

[Eric Christopher]

>  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.
>
>
How about an example here?


> >
>> >  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.
>
>
No, but it could be done as a follow on patch as part of the feature.

-eric


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