1. 09 Dec, 2009 5 commits
  2. 08 Dec, 2009 6 commits
  3. 07 Dec, 2009 11 commits
  4. 04 Dec, 2009 3 commits
  5. 05 Dec, 2009 3 commits
  6. 03 Dec, 2009 1 commit
  7. 04 Dec, 2009 1 commit
  8. 01 Oct, 2009 1 commit
  9. 30 Sep, 2009 1 commit
  10. 28 Sep, 2009 1 commit
  11. 04 Dec, 2009 2 commits
  12. 03 Dec, 2009 2 commits
    • Simon Marlow's avatar
      export g0 · 5f9075da
      Simon Marlow authored
    • Simon Marlow's avatar
      GC refactoring, remove "steps" · 214b3663
      Simon Marlow authored
      The GC had a two-level structure, G generations each of T steps.
      Steps are for aging within a generation, mostly to avoid premature
      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.
  13. 02 Dec, 2009 1 commit
  14. 04 Dec, 2009 1 commit
    • rl@cse.unsw.edu.au's avatar
      Fix loading of annotations · 99d1354f
      rl@cse.unsw.edu.au authored
      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.
  15. 03 Dec, 2009 1 commit
    • rl@cse.unsw.edu.au's avatar
      Add new ForceSpecConstr annotation · 1935c449
      rl@cse.unsw.edu.au authored
      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.