I've updated the diff to reflect the alternate non-wrapper exposure. This way requires the sanitizing of the exported objc_direct method name.

@YangZhihui landed at https://github.com/llvm/llvm-project/commit/f22d27624b6532a5542b283de9ce586c72c6b846

In D86427#2235630, @YangZhihui wrote:

how can I add the Author property in the patch
Thanks

In D86427#2235574, @YangZhihui wrote:

Thanks, but I don't have commit access

LGTM. Go ahead and land it.

@lanza I did it as a CodeGen option for now because we don't want anything like this to be the default until the ABI is fleshed out.
I think one danger in altering the name of the function to some extent is you dont want to clash potentially with user defined C functions.

Ok, LGTM. I will land for you, but in your name on git. Thanks for this patch @kyulee.

In D86049#2225202, @rjmccall wrote:

I think that, if we want to do this, we need to think carefully about what exactly we want the ABI to be.

change for clang-tidy and clang-format.

I think this LGTM. @kyulee are there any other tests that use this flag? Can you add a test that both adds and also removes some different attributes. Also a test that adds and removes he same attribute too would be good.

Good stuff. Thanks for replying so quickly @fhahn :-)

landed at https://github.com/llvm/llvm-project/commit/33490acf241a487028bfee73c0bd9e8026fcdb5c

@fhahn I ran into an llvm_unreachable when building matrix-types-spec.cpp as part of an llvm-test-suite build using -Oz with -flto=thin. I reduced the IR that hit the unreachable to:

Please Update Diff.

In D85678#2211933, @phosek wrote:

I'd be fine with InterfaceStub as a name for the library.

In D85678#2211904, @haowei wrote:

In D85678#2211863, @MaskRay wrote:

I would like to improve llvm-ifs tool on ELF object handling. Right now it uses yaml2obj which is not robust.

How is it not robust?

We contacted plotfi and learned that llvm-ifs does not work well in production when it is used for elf stub generation. We suggested to improve llvm-ifs tools and unify it with llvm-elfabi tool as they share many similarities. llvm-elfabi has its own elf handler, most of its code have not yet landed and we will try our best to make it to production grade. This CL is the first step to strip elf handler away from llvm-elfabi and put it into a standalone library so we can continue work on it and make it shared by both tools without breaking anything.

LGTM

Overall this change makes sense. I don't see why we shouldn't have this ability to remove attrs.

Closing, cause phab doesn't seem to be auto-closing.
Landed at https://github.com/llvm/llvm-project/commit/7bc03f55539f7f081daea5363f2e4845b2e75f57

In D57265#2205797, @rjf wrote:

Would also really like to see this patch landed. Also, as of today (8/10/2020), the patch cannot be cleanly applied into trunk without inducing merge conflicts anymore.

Adding BLR-based test case that explodes LR and all other registers to achieve the same assert without noreturn.

Update based on @paquette's feedback

@t.p.northover gentle ping

Solidified the cases where we want to bail out after speaking with @paquette some more

Filed a bugzilla task to track progress: https://bugs.llvm.org/show_bug.cgi?id=46767

@paquette gentle ping

Updated based on @kyulee's suggestion to use FlagsSetInAll & MachineOutlinerMBBFlags::HasCalls

In D83464#2152352, @kyulee wrote:

@plotfi I hit this in an internal workload (-Oz -flto=thin), but it won't surprise if the same issue is in llvm-test-suite.

@kyulee Did you by chance come across this on the MultiSource/Applications/Burg test on llvm-test-suite? I hit something like this with -flto=full and -Oz and have been working on debugging it.

Abandoning. I think the stuff @AndrewLitteken added a few months ago is more than sufficient.

Update for harbormaster.

@t.p.northover Hi Tim, would you have some bandwidth to take a look at this patch for homogeneous prolog/epilog callee-save registers opti?

@kyulee Update please (since the NFC has landed), so that Harbormaster can run again without conflict.

D82552 appears to have also fixed fastcc, so I will only land the test case.

@pratlucas Awesome thank you!

In D79730#2030530, @rjmccall wrote:

I think it makes sense; if nothing else, we're trying to upstream all that work.

In D66029#2052030, @mpaszkowski wrote:

@plotfi Should I create a new review so that the HarborMaster will be able run the builds after the fix?

LGTM, but I'd like @thegameg or @aemerson to take a look as well. Thanks!