llvm-project

3023c106 - [ObjCDirectPreconditionThunk] Adding a flag to with objc_direct symbols' prefix (#170616)

[ObjCDirectPreconditionThunk] Adding a flag to with objc_direct symbols' prefix (#170616) ## TL;DR This is a stack of PRs implementing features to expose direct methods ABI. You can see the RFC, design, and discussion [here](https://discourse.llvm.org/t/rfc-optimizing-code-size-of-objc-direct-by-exposing-function-symbols-and-moving-nil-checks-to-thunks/88866). The stack of the following four PRs completes the whole feature. https://github.com/llvm/llvm-project/pull/170616 **Flag `-fobjc-direct-precondition-thunk` set up** https://github.com/llvm/llvm-project/pull/170617 Code refactoring to ease later reviews https://github.com/llvm/llvm-project/pull/170618 Thunk generation https://github.com/llvm/llvm-project/pull/170619 Optimizations, some class objects can be known to be realized ## Implementation details 1. Add a flag. I used `-fobjc-direct-precondition-thunk` instead of `-fobjc-direct-caller-thunks` as discussed in this PR. 2. Clean up and set up helper functions to implement later a. `canMessageReceiverBeNull` / `canClassObjectBeUnrealized` these two functions will be helpful later to determine which function (true implementation or nil check thunk) we should dispatch a call to. Formatting. b. `getSymbolNameForMethod` has a new argument `includePrefixByte`, which allows us to erase the prefixing `\01` when the flag is enabled c. `usePreconditionThunk` is the single source of truth of what we should do. It not only checks for the flag, but also whether the method is qualified and we are in the right runtime. A method that `usePreconditionThunk` is either `shouldHavePreconditionThunk` or `shouldHavePreconditionInline`. ## Tests Driver tests --------- Signed-off-by: Peter Rong <PeterRong@meta.com> Co-authored-by: Kyungwoo Lee <kyulee@meta.com>