The mechanics look good to me as well. Thanks for the edifying discussion, too :)

LGTM aside from a few nits. Some suggested docs are above.

LGTM.

@reames/@sanjoy, do you think you'll have a chance to take a look at this soon? This is hampering LLILC's ability to use statepoints with the SysV AMD64 ABI.

Ping: I think I've addressed all feedback.

Addressed review feedback.

Expand overloaded-intrinsic-name.ll test to include an overload using a literal struct type and execute the new codepath?

Committed in r253339.

Rebased against latest changes.

Moved frame register assertions into an NDEBUG guard.

Respond to Hal's feedback re: error conditions.

Address CR feedback.

In D10977#200036, @rnk wrote:

Is it really that important to prevent people from hurting themselves by accessing ebp/rbp in a function without a frame pointer? I'd rather let them get hurt than suffer the extra code in LLVM.

Looks good aside from the pending StatepointOffset refactoring and one small comment.

LGTM.

This is looking quite a bit better. I'm going to hold off on accepting this patch until Chandler has had a chance to follow up on http://reviews.llvm.org/D10631, however.

I prefer Lang's approach as well--I certainly wouldn't mind having this checked in as an intermediate step, however.

LGTM as well.

LGTM modulo a few very minor comments.

This looks good to me as well. I'm also a bit leery of returning the call target as an argument index. Perhaps it will eventually make more sense to add an overload that operates on the call itself and returns the argument itself, but as Chandler mentioned, it's hard to tell without an example use.

+1 to Swaroop's suggestion to use an ostream rather than printf.

I don't know enough about COFF to confidently do that, and I don't have a stackmap example to copy from -- do you mind adding that bit of code once this change has landed?

Okay, I see the dependency in there now. Missed it when I glanced at that review earlier.

LGTM as well. Which later change depends on this?

Code changes LGTM. @reames, is there a list of available GC strategies that we should update?

LGTM. Thanks for doing this.

That sounds fine to me. Thanks for digging in a bit more!

LGTM. Thanks for the updates.

Please add a test case for the first assert as well (i.e. a case where relocate is returning a non-pointer type).

It would be nice to have documentation for these attributes somewhere.

I did, yes.Nearly all of the code that would be sensitive to operand indices is in StackMap.{c,h}, and it is very good about using accessors and/or symbolic offsets.

+1 to Sanjoy's comments. Thanks for doing this.

LGTM modulo the comments above.

LGTM with one nit.

Sanjoy, this might conflict with D9546. I'm happy to wait until that patch has landed before checking this in.

I do have commit access now, so I can commit this once you've signed off.

Added a test for GC transition lowering.

Expand documentation and address further CR feedback.

Expand the documentation for GC transitions and address CR feedback.

Thanks for the feedback! I'll post a new version of the code with the requested changes later today.