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.
See http://llvm.org/bugs/show_bug.cgi?id=21087:
Static arrays were passed as e.g. [2 x i16]. The LLVM lowering uses a register for each entry,
extending it to 64bit. This is not the expected behaviour.
To work around this problem the PPC ABI now uses the byval-workaround from the Win64 ABI:
The struct/array is copied to some private memory and a pointer to this memory is passed to the function.
Structs/arrays of size 1/2/4/8 are cast to an integer and passed as integer.
This fixes all codegen crashes on Linux/PPC64le.
1. Main include corresponding to .cpp file, if any.
2. DMD and LDC includes.
3. LLVM includes.
4. System includes.
Also updated a few include guards to match the default format.
The generic ABI works well with PPC64 except for LLVM PR 14779.
(http://llvm.org/bugs/show_bug.cgi?id=14779)
The new ABI infrastucture is based on the UnknownTargetABI. The
PPC64 specific parts coming soon.
This should eventually be done on x86 and x86_64 as well, but as
discussed in GitHub issue #110/pull request #120, the ABI there needs a
closer look: at least on x86_64, we need to treat static arrays exactly
like if they were a struct containing T.length members of the same type
to be compatible with DMD (as soon as the ABI is correctly implemented
there, that is).
While for this reason I want to avoid a ABI change which could silently
break some code only to change the x86 ABI again shortly after, this
commit only touches the "default" ABI for unknown targets and thus
should be safe (as we give absoultely no ABI guarantees there anyway).
crucial difference being special handling of `llvm::Type`s so they get printed
by name rather than printing their full representation (which can be positively
*huge*).
This allows re-enabling some logger calls that were disabled due to extreme
verbosity.
Applied function type from D1 frontend that got removed in D2, it's critical for member function type to be correct.
Fixed a bunch of type discrepancies in druntime object.di vs. genobj.d .
Disabled (#if 0) some potentally very large type dumps for -vv .
Updated classinfo and typeinfo generation for D2, almost complete now.
Added finer grained checks for vtbl type mismatching, aids debugging.
- Implement x86-64 extern(C), hopefully correctly.
- Tried to be a bit smarter about extern(D) while I was there.
Interestingly, this code seems to be generating more efficient code than
gcc and llvm-gcc in some edge cases, like returning a `{ [7 x i8] }` loaded from
a stack slot from an extern(C) function. (gcc generates 7 1-byte loads, while
this code generates a 4-byte, a 2-byte and a 1-byte load)
I also added some changes to make sure structs being returned from functions or
passed in as parameters are stored in memory where the rest of the backend seems
to expect them to be. These should be removed when support for first-class
aggregates improves.
