[PATCH] D57936: [CodeGenObjC] When available, emit a direct call to objc_alloc_init(cls) instead of [objc_alloc(cls) init]

Erik Pilkington via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Feb 13 18:25:20 PST 2019


erik.pilkington marked 2 inline comments as done.
erik.pilkington added inline comments.


================
Comment at: clang/lib/CodeGen/CGObjC.cpp:459
+  llvm::Value *Receiver =
+      CGF.CGM.getObjCRuntime().GetClass(CGF, ObjTy->getInterface());
+  return CGF.EmitObjCAllocInit(Receiver, CGF.ConvertType(OME->getType()));
----------------
gparker42 wrote:
> gparker42 wrote:
> > rjmccall wrote:
> > > You might need to check for a `super` message send, which can be a class message send in a class method.
> > > 
> > > Also, I think `getInterface()` can return null here, although it might need to be contrived to fit the other requirements.  `Class<SomeProtocol>`, where that protocol declares `+alloc`?  If there isn't a way to just emit the receiver pointer of a normal message send from an `ObjCMessageExpr`, that's really too bad.
> > Should this be done inside `tryGenerateSpecializedMessageSend`, or from the same place that calls `tryGenerateSpecializedMessageSend`? That position already rejects `[super …]` call sites, and might make it more obvious how the `objc_alloc` and `objc_alloc_init` optimizations interact. (Currently it takes some digging to verify that the `objc_alloc_init` generator does not need to look for the pattern `[objc_alloc(cls) init]`).
> (Never mind, that super check wouldn't help catch `[[super alloc] init]`because it's checking `init`'s receiver.)
> You might need to check for a super message send, which can be a class message send in a class method.

Ah, good catch. New patch only does this for class message sends.


================
Comment at: clang/lib/CodeGen/CGObjC.cpp:475-483
   case ObjCMessageExpr::Class: {
     ReceiverType = E->getClassReceiver();
     const ObjCObjectType *ObjTy = ReceiverType->getAs<ObjCObjectType>();
     assert(ObjTy && "Invalid Objective-C class message send");
     OID = ObjTy->getInterface();
     assert(OID && "Invalid Objective-C class message send");
     Receiver = Runtime.GetClass(*this, OID);
----------------
> Also, I think getInterface() can return null here, although it might need to be contrived to fit the other requirements. Class<SomeProtocol>, where that protocol declares +alloc? If there isn't a way to just emit the receiver pointer of a normal message send from an ObjCMessageExpr, that's really too bad.

Are you sure? It looks like we unconditionally dereference  getInterface() here, and we would take this path if not for the new check above.


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

https://reviews.llvm.org/D57936





More information about the cfe-commits mailing list