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.
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
Trying to get the alignment right by using the first non-default one
in the following order of descending priority:
VarDeclaration::alignment [variables only of course]
Type::alignment()
Type::alignsize()
This fixes `align(x) struct S { ... }`.
This is most visible on x86 (32-bit), where the stack
alignment is off otherwise.
This change is quite messy because many places assumed
that there was always exactly one LLVM parameter per
TypeFunction::parameters entry.
Now with *almost* working EH codegen. Does not compile Phobos yet
because we run into the "instruction does not dominate all uses"
issue when an r-value result of toElemDtor is used and we need to
run cleanups in between. Should easily be fixed by promoting those
values to allocas.
Most of the changes outside of ir/irfunction.{h, cpp} are just
because CreateCallOrInvoke moved locations. I took the
opportunity to also make use of the different arg count
overloads where possible.
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.
