Bad codegen for ARM (and maybe others) when optimizing

[Dan Olson via digitalmars-d-ldc]

"David Nadlinger" <code at 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