[PATCH] Support invoking the patchpoint intrinsic

Kevin Modzelewski kmod at dropbox.com
Fri Oct 3 15:17:01 PDT 2014

Oh hmm, I just checked the llvm-commits archives and I see the initial

I've had a number of issues emailing the llvm lists with my messages
getting marked as spam -- which I'm going to chalk up to Dropbox's DMARC
settings and hopefully not the content of my emails.  I wonder if that
could be the issue here?

I do remember seeing various suggestions for what to do with phabricator,
but I couldn't figure out a great way to find them.  I did read through
http://llvm.org/docs/Phabricator.html -- maybe that could be updated with
some of the more recent concerns?

On Fri, Oct 3, 2014 at 2:05 AM, Kevin Modzelewski <kmod at dropbox.com> wrote:

> 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/c8360dc9/attachment.html>

More information about the llvm-commits mailing list