[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

We just talk about it.  I agree with Nathan that we shouldn't just add this as a short-term hack; we should design the ABI right and then do what we want.

I think these are basically all the ABI questions:

- Is there a good reason to preserve signature compatibility with normal ObjC methods, or should we just drop the selector argument on direct methods?
- Should we do the null test on the caller side or the callee side?
- In direct class methods, is the caller's responsibility or the callee's to ensure that `self` is initialized?

For the first, I think dropping the argument is fine.

For the second, I'm less certain.

For the third, making it the callee's responsibility is generally better for code size but harder to optimize.  But we only have the code-size cost on the caller side when materializing from a global, and that's actually something we can also eliminate as redundant.  So maybe the best approach is to introduce a weak+hidden thunk that we use when making a call to a direct class method on a specific class, and we have that thunk do the entire materialization sequence.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86049/new/

https://reviews.llvm.org/D86049