[PATCH] D86049: RFC: Implement optional exportable wrapper function generation for objc_direct methods.

Puyan Lotfi via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Aug 20 15:16:44 PDT 2020


plotfi added a comment.

@lanza I did it as a CodeGen option for now because we don't want anything like this to be the default until the ABI is fleshed out.
I think one danger in altering the name of the function to some extent is you dont want to clash potentially with user defined C functions.

In D86049#2226507 <https://reviews.llvm.org/D86049#2226507>, @lanza wrote:

>> This change provides a codegen options flag to clang -fobjc-export-direct-method-wrappers to generate the wrapper functions that begin with the prefix objc_direct_wrapper and are marked as attribute__((alwaysinline)). This way within a link unit the wrapper functions should be inlined away at their call sites, but across a dylib boundary the wrapper call is used.
>
> I think this needing a flag is a bit magical for what seems like such a simple concept for the ObjC language. There shouldn't need to be a flag to make it work properly.
>
> We have defined more-or-less non-`virtual` methods for ObjC with `objc_direct`. The symbol visibility should behave as a reasonable developer should expect and the front end should communicate it. Requiring a flag is the compiler requiring the developer to understand compiler implementation details for his iOS app to work properly. Currently, clang decides the visibility is hidden but can't communicate this across library boundaries and you end up with confusing link errors for the developer.
>
> There's two routes that make sense in my opinion: library private and class private OR library public and class public.
>
> As per the ABI, I don't know of any reasons why `objc_direct` methods require the standard ObjC `-[class method]` signature since they won't be participating in any part of the ObjectiveC runtime. If that's the case,  a proper underscored symbol name seems like the cleaning and most reasonable fix.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86049



More information about the cfe-commits mailing list