I am going to wait for one of the Debian and or windows builder to pass successfully before merging this.

Updated comment as per aprantl's suggestion!

Tests passed on both linux/windows. Going to merge this!

Updated some tests.

Adrian, can you review?

Looked at the failures. The windows one got into LLVM and this test passed. The test that failed was:

Just fixed a comment in the code. I thinkoed the comment in the original
commit. This is NFC.

I just verified by hand that the windows builder actually ran these tests via looking at the log and they passed.

The failure on Debian an error in compiler-rt in TSAN:

I noticed that I messed up a comment (see inlined spot). I am going to wait for the testing to finish and then I am going to just update the comment and push (if I can).

In the test I purposely put in an llvm.dbg.value(undef) to make sure that we
properly propagated it through coroutine splitting so that I can use it to make
moved values unavailable. But I forgot to add it to the FileCheck... so in this small update I just added the pattern to the FileCheck.

Just publishing for review.

I looked at the other one. Beyond my question about the name, this looks great!

This is exactly what I was imagining! This will enable the frontend to opt into this optimization without having to touch the optimizer. One nit: can we use a different name than "arc_retain_agnostic". Have you considered something like "arc_inert"? My fear is that at a glance (without thinking), you would think that the attribute would have something only to do with retain when we are really talking about ARC value operations. Beyond that looks great!

I don't remember. That being said, this should be a conservative optimization. What if someone adds in the future a different global where this isn't a no-op. Is it possible if you know what the global is to add a whitelist that you only care about those 2 things.

SGTM.

I do not work on objcarc any longer. +CC Duncan.

Thanks for running it through git-clang-format. LGTM!

Did you run this through git-clang-format?

Chandler: Later tonight I am going to figure out what I need to do to my out of tree project to make this work. Hopefully everything is smooth.

I think that my response via email did not hit phabriactor. So sorry for the delay.

Added documentation.

I failed at using fabricator. I am going to close this until I get in the attribute version. That is what I meant to give to Doug to review.

Removed an unneeded static cast.

I also am not appropriate for reviewing this. Resigning as well.

LGTM.

I just prepared all of the code that I need internally to work with this and it enables me to work through/verify all my use cases. This LGTM! Thanks Chandler!

LGTM

I would comment this a little differently. I think it is good to have the Hacker's Delight mention, but IIRC LLVM has some specific rules about this. I would just ask on the list or irc. The actual implementation looks fine to me (it is exactly the same as hacker's delight).