[PATCH] D55869: Convert some ObjC retain/release msgSends to runtime calls

[Pete Cooper via Phabricator via cfe-commits]

pete added a comment.

In D55869#1337723 <https://reviews.llvm.org/D55869#1337723>, @js wrote:

> In D55869#1337711 <https://reviews.llvm.org/D55869#1337711>, @dexonsmith wrote:
>
> > In D55869#1337706 <https://reviews.llvm.org/D55869#1337706>, @js wrote:
> >
> > > The ObjFW runtime itself does not contain anything about release, retain or autorelease - these are all part of ObjFW (as in the framework). As ObjFW also supports the Apple runtime, as well as mixing with Foundation code, it so far only provides objc_retain and objc_release when they are missing, to make ARC work. They just call into the corresponding methods on the object and do nothing else.
> > >
> > > How will this change work from the Apple runtime? Will objc_retain/objc_release call the retain/release on the object if it implements its own? Should I drop my own retain/release implementation from my root object if I am compiling against the Apple runtime?
> >
> >
> > Yes, the idea is that the specialized runtime functions are fast paths for the common case, but they still fall back if the object has overridden them.
>
>
> I am guessing not just overridden, but also a root class providing one? IOW, the fast path is used when the class does not have the retain or release method at all? In that case, LGTM as is.


The Apple runtime is using a bit on each realized class to track the overriding.  The root class defaults to not having a custom RR, ie, it appears that its version of RR is considered equivalent to objc_retain.

Presumably that would apply to other root classes too, although i'm not 100% sure.  I did see some special handling of NSObject in there too so perhaps only its RR is equivalent to objc_retain/objc_release.


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

https://reviews.llvm.org/D55869