[PATCH] Support invoking the patchpoint intrinsic

[Kevin Modzelewski]

Oh, sorry about that!  I would have sworn that I entered the llvm-commits
cc on the initial review creation, but I guess I'll pay more attention next
time.


Here's the summary I put on the revision:

This is a barebones patch that enables the invoking of
llvm.experimental.patchpoint intrinsics; it's missing some things (tests,
should refactor the existing code instead of duplicating more of it), but I
wanted to send out the current version for early feedback.

I tried to just take the invoke-handling sections from the normal Invoke
path and add them to patchpoints, and it seems to work (LLVM and Pyston
tests pass), but it's hard for me to verify that I'm doing this correctly
and that it's not missing anything.

There might also need to be some discussion about whether it makes sense to
invoke patchpoints in the first place -- I think it definitely makes sense
to attach stackmap information to an invoke, but patching and statically
emitting EH information might not be coherent concepts, though on my system
it ends up working out fine.

On Thu, Oct 2, 2014 at 12:17 AM, Chandler Carruth <chandlerc at google.com>
wrote:

> Hey Andy, Kevin,
>
> Just as a heads up, this patch hit a common usage problem we have with
> Phabricator: the initial patch was created without llvm-commits, and then
> when it as added no email was actually sent to the list. So all anyone has
> seen is Andy's response.
>
> Given the widespread interest in things like patchpoint intrinsics, I
> think it would be worth updating this thread with a reasonably good
> introduction to what the patch is trying to do so that others can see it.
>
> (also, as I have mentioned in other threads about Phabricator, I strongly
> suggest that everyone using it to initiate a code review *check the mailing
> list* to ensure the first email arrived)
>
> -Chandler
>
> On Thu, Oct 2, 2014 at 12:08 AM, Andrew Trick <atrick at apple.com> wrote:
>
>> I think patching an exception throwing call is valid. You can certainly
>> have an inline cache to an exception throwing method.
>>
>> I also think it's valid to use the platform's exception handling support,
>> although probably not performant if your app throws exceptions. As Filip
>> mentioned, the best approach is to profile the throws, deoptimize when they
>> aren't expected and emit branches when they are.
>>
>> Anyway, great work. Please add tests and cleanup the code as you
>> mentioned.
>>
>> http://reviews.llvm.org/D5572
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141003/e8bb0746/attachment.html>