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.
Don't attempt to store past the end of alloca()ted memory.
This is important for structs passed in registers whose size
is not a power of 2.
Fix: alloca()te another sufficiently sized chunk, store into
it and then memcpy() the relevant bytes to the target chunk.
Ignore pointer type mismatches as long as both types are pointers;
the element type has no effect on the memory layout.
The RegCount constructor had to be improved to handle more complex
types correctly (e.g., nested structs such as { { i64, i32* } }) as
these are not rewritten anymore.
Debug unittests: only std.range-debug failing.
Not allowing dynamic arrays to be split seems to have fixed
std.stream-debug and also works for dynamic-array varargs crossing the
registers/stack boundary and extracted using core.vararg.va_arg!T().
Not sure about associative arrays and delegates yet. Delegates cannot
be rewritten using ExplicitByvalRewrite; that triggers type mismatches
somewhere.
I had another look at the official ABI specs and fixed some issues of
our classify()-based version, e.g.:
* upper half X87Up, but lower half not X87
=> pass whole argument in memory
* choose a fitting (integer/struct) type for structs/static arrays of
sizes 3,5,6,7,11,13,14,15 bytes
In case of a ctor `this` is passed to the function and is also the
return value. This is the perfect case for the `Returned` attribute.
But the x86_64 ABI missed the fact that the return value was a pointer
to a struct and did a struct rewrite, resulting in an bitcast
incompatible type.
