As we do for IrFuncTyArg. We'll need access to the front-end linkage for
the Posix ABIs too in order to implement indirect-by-value passing of
non-PODs for `extern(C++)`.
To be mangled as C++ (unsigned) long long.
For MSVC targets, D (u)long is C++-mangled as (unsigned) long long, so
there's no need for these magic structs.
For 32-bit POSIX targets, D (u)long is also a natural fit already.
For 64-bit POSIX targets however, D (u)long is C++-mangled as (unsigned)
long, so there's no corresponding D type, and these magic structs are
needed. Especially since macOS defines `int64_t` as `long long`, unlike
Linux (`long`).
Use the existing public field directly instead.
It's shorter and different than LLValue's getType() (making it easier
to discriminate DValues and LLValues for experienced LDC devs imho).
Allow ABIRewrites to return the D parameter's LL value directly.
Most rewrites store to memory anyway, so let the D parameter point
directly to that memory instead of a dedicated alloca bitcopy.
This is the bulk of the AAPCS (Procedure Call Standard for the ARM
Architecture) used for C interop. This will be used for both arm and
thumb target triples. The extern(D) ABI tries to follows the AAPCS with
a few exceptions.
Also adds the CMake infrastructure to compile and link the D source files.
The build is partially broken:
- A few files in Phobos and druntime do not build
- MSVC build is broken because of unresolved symbols involving reals
* x86: Return most POD aggregates <= 8 bytes in registers
* For extern(D), as in official Win32 D ABI specs [previously: sret]
* For all other calling conventions too, except for Linux and NetBSD
[previously: OSX and MSVC only]
* MSVC++ and extern(C++): treat structs with constructors as non-POD,
for both x86 and Win64 ABIs
* Win64: Pass and return magic C++ structs directly as LL aggregates,
rendering MSVCLongDoubleRewrite obsolete
* x86: Fix regression introduced by previous commits wrt. passing the
last struct argument in EAX register
0.15.1 used stdcall convention everywhere. But the ABI change in 0.15.2
requires use of the C calling convention for variadic calls on x86
because the stdcall convention does not support vararg functions.
Solution is to check the llvm::FunctionType if the function has varargs.
This commit also makes the C calling convention the global default
because according to the LLVM documentation the fastcc convention used
for D linkage does not support varargs.
This fixes issue #1000.
