The commit itself should be fine, but the more aggressive
inlining being done on the GC code (due to the gcbits functions
being in available in gc.gcx) seems to have uncovered a
misoptimization bug in LLVM (at least in 3.2) on x86, leading to
various unit tests failing in relase mode.
This reverts part of commit f02e4b1925.
A "statementsToo" flag was added to DMD, which disables inlining
of pretty much any functions that actually return a value – set it
to false for our purposes.
The other parts of the diff are just cosmetic.
The code to generate a constant string is too complex. Just use the
method provided by LLVM.
The complexity was introduced during a LLVM refactoring....
This reverts commit c4adbedcc, which would have fixed the
problem at its roots, but caused strange template function
attribute inference failures in D-YAML, presumably due to
the different order of semantic3 execution on the templates.
On a PowerPC target the datatype real is mapped to PPC 128bit doubledouble type.
Please note that this yet does not work if you cross compile from a different
architecture.
DMD has the obscure functionality to install functions starting with
_STI_ as global ctors and funtions starting with _STD_ as global
dtors. IMHO a pragma is a better way to specify the behaviour.
This commit adds pragma(LDC_global_crt_ctor) and
pragma(LDC_global_crt_dtor). If the pragma is specified on a function
or static method then an entry is made in the corresponding list. E.g.
in monitor_.d:
extern (C) {
#pragma(LDC_global_crt_ctor)
void _STI_monitor_staticctor()
{
// ...
}
}
This works on Linux without problems. On Windows with MS C Runtime
ctors work always but dtors are invoked only if linked against the
static C runtime. Dtors on Windows require at least LLVM 3.2.
On Windows x86_64, class TypeInfo_Struct contains 2 additional fields
(m_arg1/m_arg2) which are used for the X86_64 System V ABI varargs
implementation. They are not present on any other os.
This commit changes an assertion which did not check for the os and therefore
broke on 64bit non-86 systems like ppc64.
Referencing alloca'd memory in tail calls is invalid IR. This was
not caught by the verifier, but produced misoptimizations due to
wrong alias analysis results.
This also allows us to enable the assert in IrType::IrType.
Unfortunately, this is mostly a "peace of mind" commit, there
doesn't seem to have been a bug actually caused by the transitory
duplicate IrTypePointer/IrTypeStruct instances.
The remaining xyz2llvm static methods are not exactly pretty,
they should probably just be folded into get.
