[PATCH] D44095: [ObjC] Allow declaring __weak pointer fields in C structs in ObjC-ARC

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

LGTM, thanks.



================
Comment at: lib/CodeGen/CGNonTrivialStruct.cpp:764
+    Object = CGF->EmitObjCConsumeObject(QT, Object);
+    CGF->EmitARCStoreWeak(Addrs[DstIdx], Object, true);
+  }
----------------
ahatanak wrote:
> rjmccall wrote:
> > I guess this is the most reasonable thing to do, given that we don't have an entrypoint for it.  Please ask the ObjC runtime team to consider giving us one, though.  We could pretty easily peephole assignments into `__weak` variables where the source is loaded from a `__weak` l-value / x-value, and Swift would probably be able to take advantage of it, too.
> > 
> > You might want to go ahead and add `emitARCCopyAssignWeak` / `emitARCMoveAssignWeak` methods on CGF that do these operations and which can be optimized to use those entrypoints if/when they're added.
> Do you mean we should ask for the following objc runtime functions and use them in visitARCWeak?
> 
> ```
> // dst and src are either null or registered as __weak objects.
> void objc_copyAssignWeak(id *dst, id *src)
> void objc_moveAssignWeak(id *dst, id *src)
> ````
I meant that we should implement `emitARCCopyAssignWeak` and `emitARCMoveAssignWeak` by calling those functions if they're available, yes.

(Obviously that would be a follow-up patch, even assuming the ObjC runtime agrees to add them.)

Those functions would be specified as leaving the source in a zeroed state, which is as good as uninitialized, so they could be used for true-destructive moves as well.


https://reviews.llvm.org/D44095