GitLab

This also means that extsBitmap gets set, whereas is was just being set
to 0 before.

The regular structure type adds padding to conform to the platform ABI,
which causes problems with structures storing doubles under windows since
we don't conform to the platform ABI there. So we use packed structures
instead now that don't do any padding.

This is already handled by the Cmm code generator so LLVM is simply
duplicating work. LLVM also doesn't know which ones are actually live
so saves them all which causes a fair performance overhead for C calls
on x64. We stop llvm saving them across the call by storing undef to
them just before the call.

Patch from Erik de Castro Lopo <erikd@mega-nerd.com>.

To improve performance of the RTS when dynamically linked on x86, I
previously disabled -fPIC for certain critical modules (the GC, and a
few others).  However, build reports suggest that the dynamic linker
on OS X doesn't like this, so I'm disabling this optimsation on that
platform.

'import' syntax is seperate from ':module' syntax

We no longer support building with a compiler that doesn't come with
base 4.

Noticed by Henrique Ferreiro <hferreiro@udc.es>, thanks!

LLVM supports creating pointers in two ways, firstly through
pointer arithmetic (by casting between pointers and ints)
and secondly using the getelementptr instruction. The second way
is preferable as it gives LLVM more information to work with.

This patch changes a lot of pointer related code from the first
method to the getelementptr method.

Instead of calling the C library for these Cmm functions
we use intrinsic functions provided by llvm. LLVM will
then either create a compile time constant if possible, or
use a cpu instruction or as a last resort call the C
library.

At the moment this gives a very slight performance boost of around 1 - 2%.
Future changes to the generated code though so that pointers are kept as
pointers more often instead of being cast to integer types straight away
should hopefully improve the benefit this brings.

Validation fails when validating with PAPI support (i.e. GhcRtsWithPapi  = YES
in validate.mk).  The problem is that the posix symbols are defined by a header
included from papi.h. Compilation then fails because these symbols are
redefined in PosixSource.h. 

This patch adds an undefine for the posix symbols after including papi.h and
before including PosixSource.h. The #undefines are localized to Papi.c since
that is the only case where they are getting defined twice.