Streamlining the D ABI with the C++ one and preventing extra blits for
rvalue arguments. Non-POD arguments passed by value aren't blitted into
the callee params stack any longer, but passed by reference, either
directly (rvalue args) or as reference to a bitcopy on the caller stack
(lvalue args).
This is also a prerequisite for a potential DIP1014 (opPostMove)
implementation, as LLVM (via its `byval` attribute) has been performing
the move/blit implicitly as part of the call, with no way for us to
invoke the post-move hook afterwards in the callee with the address of
the original argument.
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++)`.
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.
Notably, the glue layer side of the changed multiple interface
inheritance layout (DMD a54e89d) has not been implemented yet.
This corresponds to DMD commit 3f6a763c0589dd03c1c206eafd434b593702564e.
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
And for sret args too, except for MSVC targets.
At least on Win64, the sret align attributes lead to ICEs for std.bitmanip
and std.uni (release only), when computing the known alignment in the LLVM
inliner pass:
Assertion failed: I->getParent()->getParent() ==
Q.CxtI->getParent()->getParent() && "Got assumption for the wrong function!",
file C:\LDC\llvm\lib\Analysis\ValueTracking.cpp, line 711
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.
