Calling C++ constructors -- looking for feedback on my approach

mboehme · May 14, 2020, 8:27pm

You mean importing, for example, the C++ constructor

ConstructorWithParam::ConstructorWithParam(int);

as

@convention(c) (Int32, @thin ConstructorWithParam.Type) -> @out ConstructorWithParam

?

This is, in fact, exactly what I'm doing (see this SIL test). In SignatureExpansion, the formal indirect result then gets lowered to a this parameter.

Correct. I think until we start deriving from C++ objects in Swift, this should be fine.

mboehme · June 9, 2020, 6:54am

@John_McCall This is now ready for review:

github.com/apple/swift

Add support for calling C++ constructors

apple:main ← martinboehme:cxx-constructors

opened 01:44PM - 25 Mar 20 UTC

martinboehme

+664 -205

A problem that we have to deal with when calling C++ constructors is that the AB…I of a C++ constructor depends not only on the signature of the constructor but on the class on which it is defined. For example, it can be necessary to pass additional “implicit” arguments to constructors of virtual base classes. It is therefore fundamentally not possible for SignatureExpansion (which doesn’t have access to the `CXXConstructorDecl`) to reliably produce the correct LLVM signature from only the type of the constructor. The approach we take is to try to get most of the way in SignatureExpansion by marking the SIL function return type with the `@out` attribute, representing the fact that C++ constructors take a `this` points to the object to be initialized. This produces an “assumed” constructor ABI in SignatureExpansion that assumes there are no implicit arguments and that the return type of the constructor ABI is void (and indeed there is no way to represent anything else in the SIL type). If this assumed ABI doesn’t match the actual ABI, we insert a thunk in IRGen. The thunk is marked `alwaysinline`, so it doesn’t incur any runtime overhead, but some compile-time overhead is required for LLVM to inline the thunk. If this turns out to be excessive, we can introduce what is essentially a peephole optimization for a full apply of a `function_ref`that refers to a C++ constructor and directly emit the constructor call in this case (along with any required implicit arguments) instead of calling the thunk. I’ve chosen not to tackle that in this PR though as it’s already large enough. On some ABIs (e.g. Itanium x64), we get lucky and the ABI for a complete constructor call always matches the assumed ABI. In addition to the core C++ constructor functionality, this PR adds some a couple of small required features: * Conversion of thin to a Clang `void` type * Handling of formal indirect results in `SignatureExpansion::expandExternalSignatureTypes()`

Would you be willing to review? Alternatively, any suggestions for who should review this?