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
Differential D56802
[CodeGenObjC] Treat ivar offsets variables as constant if they refer to ivars of a direct subclass of NSObject with an @implementation erik.pilkington on Jan 16 2019, 1:01 PM. Authored by
Details
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,
Diff Detail Event TimelineComment Actions 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. Comment Actions Also, we should just go ahead and skip using the offset variable when emitting the ivar access in the frontend. Comment Actions 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.
A method makes sense to me too. Comment Actions 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! Comment Actions 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. |