Add `ObjCDirectMethod` to `SILFunctionTypeRepresentation`, pros and cons?

Development Compiler
1

Hi all, I'm trying to implement the proposal to add attribute @objcDirect.

While I have added the keyword to AST and Sema, I am evaluating the best steps moving forward. After studying the codebase for some time I have the following plans. However, I'd like to hear some of your feedback to see if it is the best decision moving forward.

We can add a SILFunctionTypeRepresentation::ObjCDirectMethod to special case all functions marked with @objcDirect. That way, we can:

  1. easily determine that an objc method wrapper doesn't need _cmd arguments and other metadata needed to support runtime behavior
  2. set up new mangling for these functions so IRGen can remangle it to match what clang wants. Clang wants ObjCDirect method to be mangled as \01[Class(category) method] now, which SIL doesn't allow.

I'm not sure if there are any cons to it. Any feedback is appreciated. Thanks.

1 Like
2

Does the calling convention differ from regular C functions? Another possibility might be to use the existing C function representation and mangle the symbol name manually. SIL should not impose any constraints on the contents of SILFunction names.

3 Likes
3

Hmm. The need for a different representation from ObjCMethod really comes down to whether the ABI is meaningfully different apart from the dispatch mechanism, because we should be able to reliably recognize the dispatch difference at the call site. In this case, I believe the ABI is substantially different and merits its own representation.

Or we could just use the C convention, as Joe suggests. And I definitely agree with Joe that there isn't a good reason for SILFunction to be restricting symbol names.

4

Is there a dispatch mechanism other than directly calling the method implementation? If a direct method invocation always boils down to a direct function call, then lowering it to a normal C function implementation and invoking it with a static function_ref seems like it would fit in easiest with existing SIL infrastructure.

5

I agree that we should use function_ref. If the only difference was dispatch, and the calling convention otherwise matched normal ObjC methods, I think we'd want to just model these with objc_method representation and have the dispatch difference be modeled by the choice between the objc_method or function_ref instructions, the same way we do with Swift class dispatch. Since I believe we do have calling-convention differences, I think we shouldn't do that; so now we're just talking about whether we can just use the C representation or need a new objc_direct_method representation. And I guess the key question there is what exactly the convention differences look like; I forget where we've settled on the Clang side.

6

According to the commit message, self is passed as usual but _cmd is passed as garbage.

7

_cmd has been removed in ⚙ D131424 Remove the unused/undefined _cmd parameter to objc_direct methods.

now direct method only pass self, llvm-project/clang/lib/CodeGen/CGObjC.cpp at f6b4c34d4f96ca705409f76b9bb48de7d2bec9bd · llvm/llvm-project · GitHub

4 Likes
8

Sounds like using function_ref is the way to go. I've implemented that following the convention in the ObjC side.

Joe is right that SIL doesn't have any constraints on the names. But I'm still stuck on the mangling.
I'd like to use clang's mangling to avoid duplicated implementation as Becca did. However, I can't get a hold of clang::Decl unless it is imported by ClangImporter. Any help please?