Add a way to reserve temporary stack space in high-level Cmm

We occasionally need to reserve some temporary memory in a primop for
passing to a foreign function.  We've been using the stack for this,
but when we moved to high-level Cmm it became quite fragile because
primops are in high-level Cmm and the stack is supposed to be under
the control of the Cmm pipeline.

So this change puts things on a firmer footing by adding a new Cmm
construct 'reserve'.  e.g. in decodeFloat_Int#:

    reserve 2 = tmp {

      mp_tmp1  = tmp + WDS(1);
      mp_tmp_w = tmp;

      /* Perform the operation */
      ccall __decodeFloat_Int(mp_tmp1 "ptr", mp_tmp_w "ptr", arg);

      r1 = W_[mp_tmp1];
      r2 = W_[mp_tmp_w];
    }

reserve is described in CmmParse.y.

Unfortunately the argument to reserve must be a compile-time constant.
We might have to extend the parser to allow expressions with
arithmetic operators if this is too restrictive.

Note also that the return instruction for the procedure must be
outside the scope of the reserved stack area, so we have to extract
the values from the reserved area before we close the scope.  This
means some more local variables (r1, r2 in the example above).  The
generated code is more or less identical to what we had before though.
Allow the argument to 'reserve' to be a compile-time expression

By using the constant-folder to reduce it to an integer.
Update to current Cabal 1.18 branch tip

This should contain a fix that addresses the Solaris build breakage
(see #8670)

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Replace worthSplittingThunkDmd by worthSplittingArgDmd

these functions were almost equal, and neither validate nor nofib show
any difference replacing one by the other. So lets simplify this.
(This also prepares for a refactoring that will get rid of
worthSplittingArgDmd completely.)
Refactor WorkWrap, get rid of worthSplittingArgDmd

Instead of first checking whether splitting is useful, and then firing
up the worker-wrapper-machinery, which will do the same checks again, we
now simply generate a worker and wrapper, and while doing so keep track
of whether what we did was in any way useful.

So now there is only one place left where we decide whether we want to
do w/w, and that place has access to more information, in particular the
actual types at hand.
Remove unused returnsCPR
...and clean up the imports
Typos in comments
Introduce new SIZEOF_MP_LIMB_T derived constant

This allows to simplify code in `float.c` and to encode the
"sizeof(mp_limb_t) != sizeof(W_)" assumption as a compile-time
assertion.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Dont use big/small-int primops on IL32P64 (i.e. Win/x86_64) for now

This is due to `mpz_*()` functions having @long@ arguments which are
32bit on IL32P64, whereas `Int#` and `Word#` are 64bit wide, causing all
sorts of malfunction due to truncation.

This affects mostly the new big/small-int primops introduced in the
course of #8647, so when `SIZEOF_W != SIZEOF_LONG` we simply fall back
to using the big/big-int primops. big/small primops implemented via the
low-level `mpn_*()` GMP operations are not affected, as those use
`mp_limb_t` arguments.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Add an expect-broken test for Trac #8566
Tidy up Outputable.printDoc, and add printDoc_

The former adds a newline at the end (restoring the previous behaviour)
while the latter does not (which previously happened by turning the
thuing into a string and only then printing it).
Eta expand data family instances before printing them

Fixes Trac #8674
Don't print roles for data instances

See Trac #8672
Add a test case for #5949
Add testcase for #4267
Fix #8675

Haddock no longer has a generated parser, so we don't need it in the
sdist and we certainly don't want to check for it in the ./configure
script (as that would be bogus.)

Signed-off-by: Austin Seipp <austin@well-typed.com>
Enable LLVM-based code generation for FreeBSD/amd64.
Allow "amd64" to be recognized as an x86_64 platform.
Re-enable DYNAMIC_GHC_PROGRAMS for FreeBSD.

All actively supported releases (8.4-RELEASE, 9.2-RELEASE and the
upcoming 10.0-RELEASE) now support resolution of $ORIGIN properly.