This is an archive of the discontinued LLVM Phabricator instance.

[CodeGenObjC] Treat ivar offsets variables as constant if they refer to ivars of a direct subclass of NSObject with an @implementation
ClosedPublic

Authored by erik.pilkington on Jan 16 2019, 1:01 PM.

Details

Summary

This patch was originally written by Pete Cooper.

This is possible because the size of NSObject is effectively ABI, and will not change in the future. Doing this allows LLVM to avoid loading the offset.

Thanks,
Erik

Diff Detail

Repository
rC Clang

Event Timeline

We've tossed around the idea of doing things like this before, but I was hoping that it wouldn't have to be specific to NSObject and that we'd e.g. have an attribute that guarantees that the @interface declares all the ivars for a class. Are we still thinking that? Even if this is just a step towards that, I think we should at least add a method to answer whether we have a statically-known layout for the class, rather than hard-coding that decision at the leaves like this.

Also, we should just go ahead and skip using the offset variable when emitting the ivar access in the frontend.

We've tossed around the idea of doing things like this before, but I was hoping that it wouldn't have to be specific to NSObject and that we'd e.g. have an attribute that guarantees that the @interface declares all the ivars for a class. Are we still thinking that?

The attribute idea hasn't yet survived language discussions (too much of an ABI foot-gun for library evolution). But it's safe to move forward with something NSObject-specific since it's already baked into the ABI.

Even if this is just a step towards that, I think we should at least add a method to answer whether we have a statically-known layout for the class, rather than hard-coding that decision at the leaves like this.

A method makes sense to me too.

Address review comments: move the check to a function, and call it when emitting the ivar offset instead of when we emit the global. Thanks!

Emitting the global as const is probably still a good idea; if the global actually gets mapped as a constant, we'll end up making a dynamic assertion that we got the offset right. It's possible that the section will inhibit that, though.

Sure, that makes sense. The new patch makes the global constant again.

This revision is now accepted and ready to land.Jan 17 2019, 9:34 AM
This revision was automatically updated to reflect the committed changes.