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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
