[PATCH] Experimental stackmap and patchpoint intrinsic definitions.

Andrew Trick atrick at apple.com
Wed Oct 30 13:20:11 PDT 2013


On Oct 30, 2013, at 9:52 AM, Philip Reames <listmail at philipreames.com> wrote:

> 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.

Thanks Philip! This is actually a fairly small amount of code that is now becoming dwarfed by the documentation. I’ll push the non-documentation patches and also post the next documentation rewrite.

The doc review itself is becoming circular with reviewers critiquing suggestions I added from others. At this point, I’d rather let others contribute directly than serve as middle man. Maybe one more read-through would be good, after I post the rewrite, before I commit that too.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131030/18837dec/attachment.html>


More information about the llvm-commits mailing list