Ok I rebased onto r220027, but the test is passing for me. Not that that's really a good sign for the test's robustness, but I'm curious now why it's failing. I noticed that I had used a different triple than all of the other tests used so I fixed that -- I wonder if that makes it pass for you? I'm assuming you're running this on a mac so that an incorrectly-specified triple could cause issues since this assumes ELF.

Try to make the test a little bit less brittle.

Try to fix the target triple and make the intent of the test more clear

Update based on review comments

No commit access, if it looks good I'd appreciate if you could commit it :)

Sorry yes, I am comparing this approach to gc.root; it seems like gc.root and statepoints are similar in that they both take a spill+reload "reduce the code generator's ability to use copies" approach as compared to a hypothetical "track all copies so that they can be updated in place". It seems like gc.root provides much of the same functionality as statepoint -- gc.root definitely should be able to support a relocating GC as well, and I guess I haven't heard of it being "fundamentally broken" outside of a late-safepoint-placement strategy. So far the arguments I've seen for statepoints over gc.root are

• easier to save roots in callee-save registers
• easier to automatically generate gc annotations on arbitrary IR, such as post-compiler-optimizations.

Not sure how '_' got added

Address review comments

Ok I will update the patch, but I'm not sure how you mean to not thread
through the ImmutableCallSite, since I thought InvokeInst is not a subclass
of CallInst?

I think a change like this might be more compelling if you could give more detail on how it would actually help (I can't find the detail I'm looking for in your blog posts). It seems like the value of this patch is that it will work with late safepoint placement, but it'd be nice to see some examples of cases where late safepoint placement gives you something that early safepoint placement (ie by the frontend) doesn't. It kind of feels like either approach will work well with only non-gc values, and neither approach will be able to do much optimization when you do function calls. I'm not trying to claim that that's necessarily true, but it'd be easier to understand your point if there was some example IR.

Ok, I rebased onto trunk. One thing I failed to mention is that this patch depends on another that I sent out, D5657, since I wanted to separate some refactoring changes from the actual invoke-supporting change.

Rebase onto trunk (r219719)

Fix formatting

Ok, I took a more thorough look for any places that assume that
the return type is void or i64, and I was only able to find this one.

Forgot to include changes to Intrinsics.td specifying that patchpoints can now throw

Remove the refactoring changes from this CR to move to a separate one

I switched from the web interface to arc, and did not succeed in getting it to update the existing revision; closing this one in favor of the new one http://reviews.llvm.org/D5634

Looks like this feature got included in some recent broader work on TailCallElim.