"David Nadlinger" <code@klickverbot.at> writes:

> On Tuesday, 10 February 2015 at 06:07:54 UTC, Kai Nacke wrote:
>> I prefer if you follow the D ABI. My impression is that the difference between fastcc and the standard calling convention is not really great, at least on non-x86 systems.
>
> To further put this into context: LDC supported non-x86_32 platforms before the D spec ABI had that "just as C" clause. Walter's position once explicitly was that on non-x86 platforms, other compilers are "free to innovate", but that seems to have changed.
>
> And in my opinion, rightfully so. We need C ABI compatibility on all the platforms anyway, and there is little reason to also maintain a second ABI implementation. We can still relax the ABI on the IR transformation level for internal function when we are doing LTO anyway (LLVM does this by default).
>
> David

So then, I would assume that abi.cpp TargetABI::callingConv() should be changed to return llvm::CallingConv::C for Linkd?

https://github.com/ldc-developers/ldc/blob/master/gen/abi.cpp#L52

I would have thought extern(C) is enough to be compatible with native C
ABI.  We don't expect C or C++ to call extern(D) functions.  Or is the
reason for extern(D) C ABI compatibilty more to do with being compatible
with other tools like debuggers.

I now realize that up until this point on iOS, fastcc for D linkage has been used.  I did an experiment and changed to ccc for D linkage.  For some reason I start failing unittests.  I'll have to see why.

One peculiarity of fastcc (unlike ccc) is that it passes floating types in FP registers even though I am selecting softfp (i.e. use hardware FPU, but pass float types in GP registers).  The assembly code for D math functions looks awesome for fastcc when I compare to ccc.
--
Dan