GitLab

bug introduced by "threadStackUnderflow: put the new TSO on the mut
list if necessary"

Trac #3734 suggested addding some extra guidance about 
incoherence and overlap; now done

I did this in response to a suggestion in Trac #3702

The effect was that, in deeply-nested applications, FloatOut would
take quadratic time.  A good example was compiling 
    programs/barton-mangler-bug/Expected.hs
in which FloatOut had a visible pause of a couple of seconds!
Profiling showed that 40% of the entire compile time was being
consumbed by the single function partitionByMajorLevel.

The bug was that the floating bindings (type FloatBinds) was kept
as a list, which was partitioned at each binding site.  In programs
with deeply nested lists, such as
       e1 : e2 : e3 : .... : e5000 : []
this led to quadratic behaviour.

The solution is to use a proper finite-map representation;
see the new definition of FloatBinds near the bottom of FloatOut.

splitUFM :: Uniquable key => UniqFM elt -> key -> (UniqFM elt, Maybe elt, UniqFM elt)
   -- Splits a UFM into things less than, equal to, and greater than the key

This way of extending a UniqFM has existed for some time, but
we weren't really using it.

addToUFM_Acc	:: Uniquable key =>
			      (elt -> elts -> elts)	-- Add to existing
			   -> (elt -> elts)		-- New element
			   -> UniqFM elts 		-- old
			   -> key -> elt 		-- new
			   -> UniqFM elts		-- result

This is a rerecord of
    Stephen Blackheath <oversensitive.pastors.stephen@blacksapphire.com>**20090930222855
to avoid conflicts.

Otherwise you get
/tmp/ghc7602_0/ghc7602_0.s:207:0:
   non-relocatable subtraction expression, "___stginit_Lib_dyn" minus "L1x2;4"
/tmp/ghc7602_0/ghc7602_0.s:207:0:
   symbol: "___stginit_Lib_dyn" can't be undefined in a subtraction expression

This fixes aging of large objects in the new scheme.  Bug found by
perf/space_leaks/space_leak_001.  Yay perf regressions tests.

The GC had a two-level structure, G generations each of T steps.
Steps are for aging within a generation, mostly to avoid premature
promotion.  

Measurements show that more than 2 steps is almost never worthwhile,
and 1 step is usually worse than 2.  In theory fractional steps are
possible, so the ideal number of steps is somewhere between 1 and 3.
GHC's default has always been 2.

We can implement 2 steps quite straightforwardly by having each block
point to the generation to which objects in that block should be
promoted, so blocks in the nursery point to generation 0, and blocks
in gen 0 point to gen 1, and so on.

This commit removes the explicit step structures, merging generations
with steps, thus simplifying a lot of code.  Performance is
unaffected.  The tunable number of steps is now gone, although it may
be replaced in the future by a way to tune the aging in generation 0.

The problem was that we collected all annotations we knew about once when the
simplifier started and threaded them through the CoreM monad. If new interface
files were loaded during simplification, their annotations would not be
visible to the simplifier.

Now, we rebuild the annotation list at the start of every simplifier pass that
needs it (which is only SpecConstr at the moment). This ensures that we see
all annotations that have been loaded so far. This is somewhat similar to how
RULES are handled.

Annotating a type with {-# ANN type T ForceSpecConstr #-} makes SpecConstr
ignore -fspec-constr-threshold and -fspec-constr-count for recursive functions
that have arguments of type T. Such functions will be specialised regardless
of their size and there is no upper bound on the number of specialisations
that can be generated. This also works if T is embedded in other types such as
Maybe T (but not T -> T).

T should not be a product type because it could be eliminated by the
worker/wrapper transformation. For instance, in

data T = T Int Int

foo :: T -> Int
foo (T m n) = ... foo (T m' n') ...

SpecConstr will never see the T because w/w will get rid of it. I'm still
thinking about whether fixing this is worthwhile.