1. 14 Jun, 2012 1 commit
  2. 28 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Be less aggressive about the result discount · 4fa3f16d
      Simon Peyton Jones authored
      This patch fixes Trac #6099 by reducing the result discount in CoreUnfold.conSize.
      See Note [Constructor size and result discount] in CoreUnfold.
      
      The existing version is definitely too aggressive. Simon M found it an
      "unambiguous win" but it is definitely what led to the bloat. In a function
      with a lot of case branches, all returning a constructor, the discount could
      grow arbitrarily large.
      
      I also had to increase the -funfolding-creation-threshold from 450 to 750,
      otherwise some functions that should inline simply never get an unfolding.
      (The massive result discount was allow the unfolding to appear before.)
      
      The nofib results are these, picking a handful of outliers to show.
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
               fulsom          -0.5%     -1.6%     -2.8%     -2.6%    +31.1%
             maillist          -0.2%     -0.0%      0.09      0.09     -3.7%
               mandel          -0.4%     +6.6%      0.12      0.12     +0.0%
             nucleic2          -0.2%    +18.5%      0.11      0.11     +0.0%
              parstof          -0.4%     +4.0%      0.00      0.00     +0.0%
      --------------------------------------------------------------------------------
                  Min          -0.9%     -1.6%    -19.7%    -19.7%     -3.7%
                  Max          +0.3%    +18.5%     +2.7%     +2.7%    +31.1%
       Geometric Mean          -0.3%     +0.4%     -3.0%     -3.0%     +0.2%
      
      Turns out that nucleic2 has a function
        Main.$wabsolute_pos =
          \ (ww_s4oj :: Types.Tfo) (ww1_s4oo :: Types.FloatT)
            (ww2_s4op :: Types.FloatT) (ww3_s4oq :: Types.FloatT) ->
            case ww_s4oj
            of _
            { Types.Tfo a_a1sS b_a1sT c_a1sU d_a1sV e_a1sW f_a1sX g_a1sY h_a1sZ i_a1t0 tx_a1t1 ty_a1t2 tz_a1t3 ->
            (# case ww1_s4oo of _ { GHC.Types.F# x_a2sO ->
               case a_a1sS of _ { GHC.Types.F# y_a2sS ->
               case ww2_s4op of _ { GHC.Types.F# x1_X2y9 ->
               case d_a1sV of _ { GHC.Types.F# y1_X2yh ->
               case ww3_s4oq of _ { GHC.Types.F# x2_X2yj ->
               case g_a1sY of _ { GHC.Types.F# y2_X2yr ->
               case tx_a1t1 of _ { GHC.Types.F# y3_X2yn ->
               GHC.Types.F#
                 (GHC.Prim.plusFloat#
                    (GHC.Prim.plusFloat#
                       (GHC.Prim.plusFloat#
                          (GHC.Prim.timesFloat# x_a2sO y_a2sS)
                          (GHC.Prim.timesFloat# x1_X2y9 y1_X2yh))
                       (GHC.Prim.timesFloat# x2_X2yj y2_X2yr))
                    y3_X2yn)
               } } }}}}},
      
              <similar>,
              <similar> )
      
      This is pretty big, but inlining it does get rid of that F# allocation.
      But we'll also get rid of it with deep CPR: Trac #2289. For now we just
      accept the change.
      4fa3f16d
  3. 27 Apr, 2012 2 commits
    • Simon Peyton Jones's avatar
      Revert "Add -faggressive-primops" · 75336070
      Simon Peyton Jones authored
      This reverts commit 745ec959.
      
      Sigh. Seg fault
      75336070
    • Simon Peyton Jones's avatar
      Add -faggressive-primops · 745ec959
      Simon Peyton Jones authored
      I'm experimenting with making GHC a bit more aggressive about
      
        a) dropping case expressions if the result is unused
              Simplify.rebuildCase, CaseElim equation
      
        b) floating case expressions inwards
              FloatIn.fiExpr, AnnCase
      
      In both cases the new behaviour is gotten with a static (debug)
      flag -faggressive-primops.  The extra "aggression" is to allow
      discarding and floating in for side-effecting operations.  See
      the new, extensive Note [PrimOp can_fail and has_side_effects]
      and Note [Aggressive PrimOps] in PrimoOp.
      
      When discarding a case with unused binders, in the lifted-type
      case it's definitely ok if the scrutinee terminates; previously
      we were checking exprOkForSpeculation, which is significantly
      worse.
      
      There's a related change to CoreUtils/CoreArity, but I'll put that
      in the next commit.
      745ec959
  4. 11 Apr, 2012 1 commit
  5. 16 Jan, 2012 1 commit
  6. 13 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Add -faggressive-primops plus refactoring in CoreUtils · 601c983d
      Simon Peyton Jones authored
      I'm experimenting with making GHC a bit more aggressive about
        a) dropping case expressions if the result is unused
              Simplify.rebuildCase, CaseElim equation
      
        b) floating case expressions inwards
              FloatIn.fiExpr, AnnCase
      
      In both cases the new behaviour is gotten with a static (debug)
      flag -faggressive-primops.  The extra "aggression" is to allow
      discarding and floating in for side-effecting operations.  See
      the new, extensive Note [PrimOp can_fail and has_side_effects]
      in PrimoOp.
      
      When discarding a case with unused binders, in the lifted-type
      case it's definitely ok if the scrutinee terminates; previously
      we were checking exprOkForSpeculation, which is significantly
      worse.
      
      So I wanted a new function CoreUtils.exprCertainlyTerminates.
      In doing this I ended up with a significant refactoring in
      CoreUtils.  The new structure has quite a lot of nice sharing:
      
          exprIsCheap             = exprIsCheap' isHNFApp
          exprIsExpandable        = exprIsCheap' isConLikeApp
      
          exprIsHNF               = exprIsHNFlike isHNFApp
          exprIsConLike           = exprIsHNFlike isConLikeApp
          exprCertainlyTerminates = exprIsHNFlike isTerminatingApp
      601c983d
  7. 28 Nov, 2011 1 commit
  8. 25 Nov, 2011 1 commit
  9. 04 Nov, 2011 1 commit
  10. 17 Oct, 2011 1 commit
  11. 25 Aug, 2011 1 commit
  12. 29 Jul, 2011 1 commit
    • batterseapower's avatar
      Add CoreMonad.reinitializeGlobals so plugins can work around linker issues · 0e765db4
      batterseapower authored
      When a plugin is loaded, it currently gets linked against a *newly loaded* copy
      of the GHC package. This would not be a problem, except that the new copy has its
      own mutable state that is not shared with that state that has already been initialized by
      the original GHC package.
      
      This leads to loaded plugins calling GHC code which pokes the static flags,
      and then dying with a panic because the static flags *it* sees are uninitialized.
      
      There are two possible solutions:
        1. Export the symbols from the GHC executable from the GHC library and link
           against this existing copy rather than a new copy of the GHC library
        2. Carefully ensure that the global state in the two copies of the GHC
           library matches
      
      I tried 1. and it *almost* works (and speeds up plugin load times!) except
      on Windows. On Windows the GHC library tends to export more than 65536 symbols
      (see #5292) which overflows the limit of what we can export from the EXE and
      causes breakage.
      
      (Note that if the GHC exeecutable was dynamically linked this wouldn't be a problem,
      because we could share the GHC library it links to.)
      
      We are going to try 2. instead. Unfortunately, this means that every plugin
      will have to say `reinitializeGlobals` before it does anything, but never mind.
      
      I've threaded the cr_globals through CoreM rather than giving them as an
      argument to the plugin function so that we can turn this function into
      (return ()) without breaking any plugins when we eventually get 1. working.
      0e765db4
  13. 15 Jul, 2011 1 commit
  14. 26 Jun, 2011 1 commit
  15. 25 May, 2011 1 commit
  16. 21 Apr, 2011 1 commit
  17. 14 Apr, 2011 1 commit
  18. 31 Mar, 2011 1 commit
  19. 10 Dec, 2010 1 commit
  20. 08 Dec, 2010 4 commits
  21. 28 Oct, 2010 1 commit
  22. 07 Oct, 2010 1 commit
  23. 23 Sep, 2010 1 commit
  24. 18 Sep, 2010 1 commit
  25. 13 Sep, 2010 1 commit
  26. 30 Aug, 2010 1 commit
  27. 27 May, 2010 1 commit
  28. 06 Jan, 2010 1 commit
  29. 02 Jan, 2010 1 commit
  30. 28 Sep, 2009 1 commit
  31. 04 Nov, 2009 1 commit
  32. 29 Oct, 2009 1 commit
  33. 20 Oct, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Allow -ticky and -prof together · 8277f2dc
      simonpj@microsoft.com authored
      The two used to be incompatible, but they aren't any longer.
      
      In fact, -ticky should not be a 'way' any more, and doing that
      is on Simon M's todo list, but this patch takes us a little
      step closer.
      
      I'm not sure this is worth merging to the 6.12 branch.
      8277f2dc
  34. 14 Oct, 2009 1 commit
  35. 29 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Unify event logging and debug tracing. · a5288c55
      Simon Marlow authored
        - tracing facilities are now enabled with -DTRACING, and -DDEBUG
          additionally enables debug-tracing.  -DEVENTLOG has been
          removed.
      
        - -debug now implies -eventlog
      
        - events can be printed to stderr instead of being sent to the
          binary .eventlog file by adding +RTS -v (which is implied by the
          +RTS -Dx options).
      
        - -Dx debug messages can be sent to the binary .eventlog file
          by adding +RTS -l.  This should help debugging by reducing
          the impact of debug tracing on execution time.
      
        - Various debug messages that duplicated the information in events
          have been removed.
      a5288c55
  36. 20 Aug, 2009 1 commit