GitLab

These array types are smaller than Array# and MutableArray# and are
faster when the array size is small, as they don't have the overhead
of a card table. Having no card table reduces the closure size with 2
words in the typical small array case and leads to less work when
updating or GC:ing the array.

Reduces both the runtime and memory allocation by 8.8% on my insert
benchmark for the HashMap type in the unordered-containers package,
which makes use of lots of small arrays. With tuned GC settings
(i.e. `+RTS -A6M`) the runtime reduction is 15%.

Fixes #8923.

This should reduce code size when there's little to gain from inlining
these primops, while still retaining the inlining benefit when the
size of the copy is known statically.

Signed-off-by: Austin Seipp <austin@well-typed.com>

This adds -fmax-inline-memcpy-insns and -fmax-inline-memset-insns.
These flags control when we inline calls to memcpy/memset with
statically known arguments. The flag naming style is taken from GCC
and the same limit is used by both GCC and LLVM.

I've added detailed comments with
  Note [Decomposing the left-hand side of a RULE]

The result is a noticeable improvement.  Previously

 * we rejected a perfectly decent SPECIALISE (Trac #8848)

 * and for something like
      f :: (Eq a) => b -> a -> a
      {-# SPECIALISE f :: b -> [Int] -> [Int] #-}
   we ended up with
      RULE  f ($fdEqList $dfEqInt) = f_spec
   whereas we wanted
      RULES forall (d:Eq [Int]). f d = f_spec

This patch makes the simplifier eliminate a redundant seq like
    case x of y -> ...y....
where y is used strictly.  GHC used to do this, but I made it less
aggressive in

   commit 28d9a032 (Jan 2013)

However #8900 shows that doing so sometimes loses good
transformations; and the transformation is valid according to "A
semantics for imprecise exceptions".  So I'm restoring the old
behaviour.

See Note [Eliminating redundant seqs]

Trac #8912 pointed out that GHC 7.4 and 7.6 have omitted this test, although
7.2 and earlier had it.  This patch puts the test back in, and refactors a
little.

There was a special case in rewriteEvidence, looking like:
  = return (Just (if ctEvPred old_ev `tcEqType` new_pred
                  then old_ev
                  else old_ev { ctev_pred = new_pred }))

But this was wrong: old_pred and new_pred might differ in the kind
of a TyVar occurrence, in which case tcEqType would not notice,
but we really, really want new_pred.  This caused Trac #8913.

I solved this by dropping the whole test, and instead making
the flattener preserve type synonyms. This was easy because
TcEvidence has TcTyConAppCo which (unlike) Coercion, handles
synonyms.

This change makes the code for canIrred markedly simpler (and more efficient)
See Note [Equalities with incompatible kinds].

I don't think there was really a bug here, but I came across it when
fixing Trac #8913

This wasn't showing up as a bug, but it was definitely wrong.

See #8827 - for now, we're making GND unsafe again.

This also fixes the tests since they were originally not using the new
unicode quote style we're using.

This reverts commit a8a01e74.

This patch is really a fix to the big commint
   73c08ab1
   Re-work the naming story for the GHCi prompt (Trac #8649)
which introduced the 'interactive' package
See Note [The interactive package] in HscTypes

The original commit set both
  (a) The tcg_mod field of TcGblEnv to 'interactive:Ghci4' (say)
  (b) The thisPackage field of DynFlags to 'interactive'

But the second step interacts badly with linking.  :loaded modules are
in the package set by 'thisPackage' (usually 'main'); if you change
that, then we try to link package 'main', but can't find it, and
that is what happened in #8831.

The fix was simple: do (a) but not (b).

I changed Note [The interactive package] in HscTypes to describe this.

I've elaboated Note [Unify kinds in deriving] to explain
what is going on here.

The change fixes Trac #8893.

FamInstEnv.normaliseTcApp should normalise arguments even when
the top-level tycon isn't a type family. This was a regression
from 7.6 -- not sure when it happened, but it was probably my
fault. Fixed now, in any case.

Previously, the closed type family compatibility check was
done even when type-checking an interface file. But interface
files now store compatibility info, so this check was redundant.

The inline allocation version is 69% faster than the out-of-line
version, when cloning an array of 16 unit elements on a 64-bit
machine.

Comparing the new and the old primop implementations isn't
straightforward. The old version had a missing heap check that I
discovered during the development of the new version. Comparing the
old and the new version would requiring fixing the old version, which
in turn means reimplementing the equivalent of MAYBE_CG in StgCmmPrim.

The inline allocation threshold is configurable via
-fmax-inline-alloc-size which gives the maximum array size, in bytes,
to allocate inline. The size does not include the closure header size.

Allowing the same primop to be either inline or out-of-line has some
implication for how we lay out heap checks. We always place a heap
check around out-of-line primops, as they may allocate outside of our
knowledge. However, for the inline primops we only allow allocation
via the standard means (i.e. virtHp). Since the clone primops might be
either inline or out-of-line the heap check layout code now consults
shouldInlinePrimOp to know whether a primop will be inlined.

Signed-off-by: Austin Seipp <austin@well-typed.com>

This is so that generated names like e.g. workers don't show up as
infix operators when using something like -ddump-simpl.

This is done with two built-in type families: `CmpNat and `CmpSymbol`.
Both of these return a promoted `Ordering` type (EQ, LT, or GT).

For DFunUnfoldings we were failing to occurrence-analyse the unfolding,
and that meant that a loop breaker wasn't marked as such, which in turn
meant it was inlined away when it still had occurrence sites.  See
Note [Occurrrence analysis of unfoldings] in CoreUnfold.

This is a pretty long-standing bug, happily nailed by John Lato.

We don't yet understand WHY commit ad15c2, which is to do with
CmmSink, causes seg-faults on Windows, but it certainly seems to.  So
reverting it is a stop-gap, but we need to un-block the 7.8 release.

Many thanks to awson for identifying the offending commit.

There was even a comment to warn about this possiblity,
and it finally showed up in practice!  This patch fixes
it quite nicely, with commens to explain.

so do not export it in GHC.Prim, and also have the pseudo-code for
GHC.Prim import GHC.Types, so that haddock is happy.

This is a followup to the fix for #8827, and should be merged
with that change.

Even if the recursion is a nice tail-call only recusion, we'd stil be
calling the thunk multiple times and eta-expansion would be wrong.
Includes a [Note].

(Also shows the disadvantage of unit tests: They had the same bug.)