The check was never fully implemented. We need to look into
this again, as currently we fail with a fairly unintellegible
LLVM ICE (added as GitHub #).
The issue was that when merging in the old attributes, attrs
wasn't assigned to, thus silently dropping all of them
(leading e.g. to noinline being omitted on functions containing
inline asm).
The new code hopefully also makes the intent clearer.
Starting with LLVM 3.3 a new parameter attribute `returned` is supported.
The attribute states that the parameter is the return value, too. This is the
case in constructors. (Destructors and postblits do not return `this`.)
Attribute `returned` is now added to the `this` parameter of constructors.
I have seen it used several times in benchmarks comparing it
to 'gdc -O3' and 'dmd -O -inline' now, so people apparently
expect it to yield the highest available optimization level.
In some cases an assertion is triggered because the debug context of a
local variale is verified. It turns out that LLVM returns always false
for DISubprogram.Verify() if the return type is not a composite type.
Reading the Clang source it looks like the return type must be a
subroutine type. This commit introduces a dummy subroutine type to
define the return type.
LDC_never_inline is a complementary intrinsic to LDC_allow_inline.
It tells the LLVM optimizer to never inline a function. This can be
useful if inlining creates incorrect code.
A possible application is core.thread.getStackTop().
These intrinsics operate on size_t words. The generated LLVM IR operates
on bytes and therefore assumes a little-endian architecture.
The fix is to change the generated IR to work on size_t words.
We can't simply use the C calling convention, as the D(MD)
ABI is callee-pop, and this is hardcoded in naked functions
with stack parameters.
The \1 "trick" is normally used to avoid prefixes added by
LLVM; on the 3.2 release, a patch is needed to make it work
for the @<n> stdcall suffixes as well.
David Nadlinger