[PATCH] Experimental stackmap and patchpoint intrinsic definitions.

[Philip Reames]

On 10/29/13 10:51 AM, Andrew Trick wrote:
> On Oct 28, 2013, at 11:45 AM, Juergen Ributzka <juergen at apple.com> wrote:
>
>> Hi Chris,
>>
>> 1.) The return type of the patchpoint intrinsic is independent of any of its arguments, so we couldn’t use the LLVMMatchType to let tblgen pattern match all the possible intrinsic names for us. A more generic approach would require extending tblgen to also handle this case.
>>
>> 2.) Not sure what you mean, because both patchpoint intrinsic versions take llvm_ptr_ty as an argument (3rd argument).
>>
>> Cheers,
>> Juergen
>>
>> On Oct 26, 2013, at 6:04 PM, Chris Lattner <clattner at apple.com> wrote:
>>
>>> On Oct 21, 2013, at 8:11 PM, Andrew Trick <atrick at apple.com> wrote:
>>>
>>>> Hi lhames, ributzka, echristo,
>>>>
>>>> These new intrinsics require varargs support.
>>> Why is the _void and _i64 embedded into the intrinsic name?  For the first one, are you expecting other versions of this?  On the second, can/should it just take a llvm_ptr_ty, so that it is properly generic over any pointer type?
> Juergen’s answer above is correct. I can rephrase.
>
> llvm.experimental.safepoint only has/will have a single version of the intrinsic.
>
> llvm.experimental.patchpoint implies a safepoint but adds call-like semantics. Each return type that we support needs a different version of the intrinsic. WebKit only needs two: void and i64. I suggested i8* and double variants but they aren’t interested in using them yet. I’m happy to add speculative features, but my current policy is strictly as-needed.
>
> I don’t think there are any objections to the patch at this point. If anyone wants more time/discussion please let me know.
>
> -Andy
>
There's still some room for incremental improvement, but the current 
state of the patches is useful enough to have in tree as is.  I would 
recommend not holding them any further.

Philip