GitLab

Patch from Michal Terepeta <michal.terepeta@gmail.com>

* phonohawk/patch-5408:
  Resurrect UseLibFFIForAdjustors from bitrot.
  Detect cases where as(1) doesn't recognise .ident directive (#5408)

* Pass -Irts/dist/build to the C preprocessor to expose libffi headers (ffi.h and ffitarget.h) to foreign import wrappers during the building process of GHC itself.
* Install libffi headers into $(ghcheaderdir) just like any other C headers. Otherwise an installed GHC can't find them when it wants to compile foreign import wrappers.
* Include libffi headers in the bindist for the same reason.

.ident directives are usually ignored by as(1), and in some cases (like Darwin/PPC) they even raise an error.

We had some special cases to handle things like

  case (scc c (case E of alts)) of alts'

but it only worked when there was a single scc in the way.  This
generalises the optimisation to handle multiple sccs and ticks, so
that we can catch most case-of-case optimisations that would normally
apply in the absence of profiling.

This fixes the example in #5363, and nofib results (with -prof
-fprof-auto) show that allocation universally goes down or stays the
same.

The primitive array types, such as 'ByteArray#', have kind #, but are represented by pointers. They are boxed, but unpointed types (i.e., they cannot be 'undefined').

The two categories of array types —[Mutable]Array# and [Mutable]ByteArray#— are containers for unboxed (and unpointed) as well as for boxed and pointed types.  So far, we lacked support for containers for boxed, unpointed types (i.e., containers for the primitive arrays themselves).  This is what the new primtypes provide.

Containers for boxed, unpointed types are crucial for the efficient implementation of scattered nested arrays, which are central to the new DPH backend library dph-lifted-vseg.  Without such containers, we cannot eliminate all unboxing from the inner loops of traversals processing scattered nested arrays.

Some of the nightly builders have been running out of memory when
running it.

At present the number of capabilities can only be *increased*, not
decreased.  The latter presents a few more challenges!

Consider this experimental for the time being.  There are a lot of
things that could go wrong, but I've verified that at least it works
on the test cases we have.

I also did some API cleanups while I was here.  Previously we had:

Capability * rts_eval (Capability *cap, HaskellObj p, /*out*/HaskellObj *ret);

but this API is particularly error-prone: if you forget to discard the
Capability * you passed in and use the return value instead, then
you're in for subtle bugs with +RTS -N later on.  So I changed all
these functions to this form:

void rts_eval (/* inout */ Capability **cap,
               /* in    */ HaskellObj p,
               /* out */   HaskellObj *ret)

It's much harder to use this version incorrectly, because you have to
pass the Capability in by reference.

If they're not marked as can_fail, then they are floated out of case expressions that check whether the indices are in-bounds, causing immense suffering.

Peter Wortmann authored Dec 05, 2011 and dterei committed Dec 05, 2011

Otherwise the LLVM backend gets confused over whether its type should be
"void (i8*, i8*)" or "i64 (i8*, i8*)".
Signed-off-by: David Terei <davidterei@gmail.com>

LLVM has a problem when the user imports some FFI types
like memcpy and memset in a manner that conflicts with
the types that GHC uses internally.

So now we pre-initialise the environment with the most
general types for these functions.

The main idea is that when we unify
    forall a. t1  ~  forall a. t2
we get constraints from unifying t1~t2 that mention a.
We are producing a coercion witnessing the equivalence of
the for-alls, and inside *that* coercion we need bindings
for the solved constraints arising from t1~t2.

We didn't have way to do this before.  The big change is
that here's a new type TcEvidence.TcCoercion, which is
much like Coercion.Coercion except that there's a slot
for TcEvBinds in it.

This has a wave of follow-on changes. Not deep but broad.

* New module TcEvidence, which now contains the HsWrapper
  TcEvBinds, EvTerm etc types that used to be in HsBinds

* The typechecker works exclusively in terms of TcCoercion.

* The desugarer converts TcCoercion to Coercion

* The main payload is in TcUnify.unifySigmaTy. This is the
  function that had a gross hack before, but is now beautiful.

* LCoercion is gone!  Hooray.

Many many fiddly changes in conssequence.  But it's nice.

We no longer generate them, but they may be in existing GHC trees,
so we'll keep cleaning them for a while.

Compile time still isn't as good as I'd like but no easy changes
available. LLVM backend could do with a big rewrite to improve
performance as there are some ugly designs in it.

At least the test case isn't 10min anymore, just a few seconds now.

They made a dependency cycle in the rules used to build the touch
program on Windows.

When they existed, they were getting included in the includes_H_FILES
variable (as it uses wildcard to find all header files). But the
.depends files for the programs that generate the headers depend on
$(includes_H_FILES), so the .depends files looked out-of-date once the
headers had been created. This caused unnecessary make reinvocations.

So now we put them in dist* directories, where they ought to be anyway.