1. 07 Dec, 2011 1 commit
    • Simon Marlow's avatar
      Improve optimisation in the presence of SCCs (fixes #5363) · eea40328
      Simon Marlow authored
      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.
      eea40328
  2. 16 Nov, 2011 1 commit
  3. 14 Nov, 2011 2 commits
  4. 11 Nov, 2011 2 commits
  5. 10 Nov, 2011 1 commit
  6. 09 Nov, 2011 1 commit
  7. 04 Nov, 2011 2 commits
    • Simon Marlow's avatar
      Improve optimisation for ticks · 659d5d06
      Simon Marlow authored
      We want to prevent the SCC from getting in the way when we have
      case-of-scc-of-case, and the case-of-case would transform, so we push
      the scc inside the inner case to allow the case-of-case to take
      place.  See comments for details.
      659d5d06
    • Ian Lynagh's avatar
      Use -fwarn-tabs when validating · 1df19864
      Ian Lynagh authored
      We only use it for "compiler" sources, i.e. not for libraries.
      Many modules have a -fno-warn-tabs kludge for now.
      1df19864
  8. 02 Nov, 2011 2 commits
    • Simon Marlow's avatar
      be9e727c
    • Simon Marlow's avatar
      Overhaul of infrastructure for profiling, coverage (HPC) and breakpoints · 7bb0447d
      Simon Marlow authored
      User visible changes
      ====================
      
      Profilng
      --------
      
      Flags renamed (the old ones are still accepted for now):
      
        OLD            NEW
        ---------      ------------
        -auto-all      -fprof-auto
        -auto          -fprof-exported
        -caf-all       -fprof-cafs
      
      New flags:
      
        -fprof-auto              Annotates all bindings (not just top-level
                                 ones) with SCCs
      
        -fprof-top               Annotates just top-level bindings with SCCs
      
        -fprof-exported          Annotates just exported bindings with SCCs
      
        -fprof-no-count-entries  Do not maintain entry counts when profiling
                                 (can make profiled code go faster; useful with
                                 heap profiling where entry counts are not used)
      
      Cost-centre stacks have a new semantics, which should in most cases
      result in more useful and intuitive profiles.  If you find this not to
      be the case, please let me know.  This is the area where I have been
      experimenting most, and the current solution is probably not the
      final version, however it does address all the outstanding bugs and
      seems to be better than GHC 7.2.
      
      Stack traces
      ------------
      
      +RTS -xc now gives more information.  If the exception originates from
      a CAF (as is common, because GHC tends to lift exceptions out to the
      top-level), then the RTS walks up the stack and reports the stack in
      the enclosing update frame(s).
      
      Result: +RTS -xc is much more useful now - but you still have to
      compile for profiling to get it.  I've played around a little with
      adding 'head []' to GHC itself, and +RTS -xc does pinpoint the problem
      quite accurately.
      
      I plan to add more facilities for stack tracing (e.g. in GHCi) in the
      future.
      
      Coverage (HPC)
      --------------
      
       * derived instances are now coloured yellow if they weren't used
       * likewise record field names
       * entry counts are more accurate (hpc --fun-entry-count)
       * tab width is now correct (markup was previously off in source with
         tabs)
      
      Internal changes
      ================
      
      In Core, the Note constructor has been replaced by
      
              Tick (Tickish b) (Expr b)
      
      which is used to represent all the kinds of source annotation we
      support: profiling SCCs, HPC ticks, and GHCi breakpoints.
      
      Depending on the properties of the Tickish, different transformations
      apply to Tick.  See CoreUtils.mkTick for details.
      
      Tickets
      =======
      
      This commit closes the following tickets, test cases to follow:
      
        - Close #2552: not a bug, but the behaviour is now more intuitive
          (test is T2552)
      
        - Close #680 (test is T680)
      
        - Close #1531 (test is result001)
      
        - Close #949 (test is T949)
      
        - Close #2466: test case has bitrotted (doesn't compile against current
          version of vector-space package)
      7bb0447d
  9. 23 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Add a transformation limit to the simplifier (Trac #5448) · 24a2353a
      Simon Peyton Jones authored
      This addresses the rare cases where the simplifier diverges
      (see the above ticket).  We were already counting how many simplifier
      steps were taking place, but with no limit.  This patch adds a limit;
      at which point we halt compilation, and print out useful stats. The
      stats show what is begin inlined, and how often, which points you
      directly to the problem.  The limit is set based on the size of the
      program.
      
      Instead of halting compilation, we could instead just inhibit
      inlining, which would let compilation of the module complete. This is
      a bit harder to implement, and it's likely to mean that you unrolled
      the function 1143 times and then ran out of ticks; you probably don't
      want to complete parsing on this highly-unrolled program.
      
      Flags: -dsimpl-tick-factor=N.  Default is 100 (percent).
             A bigger number increases the allowed maximum tick count.
      24a2353a
  10. 07 Sep, 2011 1 commit
  11. 06 Sep, 2011 1 commit
  12. 21 Jul, 2011 1 commit
    • Simon Peyton Jones's avatar
      Simplify the treatment of RULES in OccurAnal · f88b20f4
      Simon Peyton Jones authored
      I realised that my recently-added cunning stuff about
      RULES for imported Ids was simply wrong, so this patch
      removes it.   See Note [Rules for imported functions],
      which explains it all.
      
      This patch also does quite a bit of refactoring in
      the treatment of loop breakers.
      f88b20f4
  13. 15 Jul, 2011 1 commit
  14. 23 Jun, 2011 1 commit
  15. 12 May, 2011 1 commit
    • Simon Peyton Jones's avatar
      The final batch of changes for the new coercion representation · c8c2f6bb
      Simon Peyton Jones authored
      * Fix bugs in the packing and unpacking of data
        constructors with equality predicates in their types
      
      * Remove PredCo altogether; instead, coercions between predicated
        types (like  (Eq a, [a]~b) => blah) are treated as if they
        were precisely their underlying representation type
             Eq a -> ((~) [a] b) -> blah
        in this case
      
      * Similarly, Type.coreView no longer treats equality
        predciates specially.
      
      * Implement the cast-of-coercion optimisation in
        Simplify.simplCoercionF
      
      Numerous other small bug-fixes and refactorings.
      
      Annoyingly, OptCoercion had Windows line endings, and this
      patch switches to Unix, so it looks as if every line has changed.
      c8c2f6bb
  16. 20 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      Add pprDefiniteTrace and use it · b187c221
      Simon Peyton Jones authored
      The point here is that a very few uses of pprTrace are
      controlled by a flag like -ddump-inlinings or -ddump-rule-firings,
      and we want to see that output even with -dno-debug-output
      b187c221
  17. 19 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      This BIG PATCH contains most of the work for the New Coercion Representation · fdf86568
      Simon Peyton Jones authored
      See the paper "Practical aspects of evidence based compilation in System FC"
      
      * Coercion becomes a data type, distinct from Type
      
      * Coercions become value-level things, rather than type-level things,
        (although the value is zero bits wide, like the State token)
        A consequence is that a coerion abstraction increases the arity by 1
        (just like a dictionary abstraction)
      
      * There is a new constructor in CoreExpr, namely Coercion, to inject
        coercions into terms
      fdf86568
  18. 02 Mar, 2011 1 commit
  19. 14 Feb, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Better case-of-case transformation · 7a50e6d8
      simonpj@microsoft.com authored
      The ThunkSplitting idea in WorkWrap wasn't working at all,
      leading to Trac #4957.  The culprit is really the simplifier
      which was combining the wrong case continuations. See
      Note [Fusing case continuations] in Simplify.
      7a50e6d8
  20. 01 Feb, 2011 1 commit
  21. 31 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Improve Simplifier and SpecConstr behaviour · 70ad6e6a
      simonpj@microsoft.com authored
      Trac #4908 identified a case where SpecConstr wasn't "seeing" a
      specialisation it should easily get.  The solution was simple: see
      Note [Add scrutinee to ValueEnv too] in SpecConstr.
      
      Then it turned out that there was an exactly analogous infelicity in
      the mighty Simplifer too; see Note [Add unfolding for scrutinee] in
      Simplify. This fix is good for Simplify even in the absence of the
      SpecConstr change.  (It arose when I moved the binder- swap stuff to
      OccAnall, not realising that it *remains* valuable to record info
      about the scrutinee of a case expression.  The Note says why.
      
      Together these two changes are unconditionally good.  Better
      simplification, better specialisation. Thank you Max.
      70ad6e6a
  22. 25 Jan, 2011 1 commit
  23. 21 Dec, 2010 1 commit
  24. 13 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix recursive superclasses (again). Fixes Trac #4809. · a3bab050
      simonpj@microsoft.com authored
      This patch finally deals with the super-delicate question of
      superclases in possibly-recursive dictionaries.  The key idea
      is the DFun Superclass Invariant (see TcInstDcls):
      
           In the body of a DFun, every superclass argument to the
           returned dictionary is
             either   * one of the arguments of the DFun,
             or       * constant, bound at top level
      
      To establish the invariant, we add new "silent" superclass
      argument(s) to each dfun, so that the dfun does not do superclass
      selection internally.  There's a bit of hoo-ha to make sure that
      we don't print those silent arguments in error messages; a knock
      on effect was a change in interface-file format.
      
      A second change is that instead of the complex and fragile
      "self dictionary binding" in TcInstDcls and TcClassDcl,
      using the same mechanism for existential pattern bindings.
      See Note [Subtle interaction of recursion and overlap] in TcInstDcls
      and Note [Binding when looking up instances] in InstEnv.
      
      Main notes are here:
      
        * Note [Silent Superclass Arguments] in TcInstDcls,
          including the DFun Superclass Invariant
      
      Main code changes are:
      
        * The code for MkId.mkDictFunId and mkDictFunTy
      
        * DFunUnfoldings get a little more complicated;
          their arguments are a new type DFunArg (in CoreSyn)
      
        * No "self" argument in tcInstanceMethod
        * No special tcSimplifySuperClasss
        * No "dependents" argument to EvDFunApp
      
      IMPORTANT
         It turns out that it's quite tricky to generate the right
         DFunUnfolding for a specialised dfun, when you use SPECIALISE
         INSTANCE.  For now I've just commented it out (in DsBinds) but
         that'll lose some optimisation, and I need to get back to
         this.
      a3bab050
  25. 08 Dec, 2010 1 commit
  26. 27 Nov, 2010 1 commit
    • rl@cse.unsw.edu.au's avatar
      New flag -dddump-rule-rewrites · 9c84f11b
      rl@cse.unsw.edu.au authored
      Now, -ddump-rule-firings only shows the names of the rules that fired (it would
      show "before" and "after" with -dverbose-core2core previously) and
      -ddump-rule-rewrites always shows the "before" and "after" bits, even without
      -dverbose-core2core.
      9c84f11b
  27. 16 Nov, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Refactoring of the way that inlinings and rules are activated · c177e43f
      simonpj@microsoft.com authored
      Principally, the SimplifierMode now carries several (currently
      four) flags in *all* phases, not just the "Gentle" phase.
      This makes things simpler and more uniform.
      
      As usual I did more refactoring than I had intended.
      
      This stuff should go into 7.0.2 in due course, once
      we've checked it solves the DPH performance problems.
      c177e43f
  28. 27 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Two signficant changes to the simplifier · f95a9542
      simonpj@microsoft.com authored
      1. Do eta-expansion at let-bindings, not lambdas.
         I have wanted to do this for a long time.
         See Note [Eta-expanding at let bindings] in SimplUtils
      
      2. Simplify the rather subtle way in which InlineRules (the
         template captured by an INLINE pragma) was simplified.
         Now, these templates are always simplified in "gentle"
         mode only, and only INLINE things inline inside them.
      
         See Note Note [Gentle mode], Note [Inlining in gentle mode]
         and Note [RULEs enabled in SimplGently] in SimplUtils
      f95a9542
  29. 20 Oct, 2010 1 commit
  30. 15 Oct, 2010 1 commit
  31. 07 Oct, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Avoid redundant simplification · fb982282
      simonpj@microsoft.com authored
      When adding specialisation for imported Ids, I noticed that the
      Glorious Simplifier was repeatedly (and fruitlessly) simplifying the
      same term.  It turned out to be easy to fix this, because I already
      had a flag in the ApplyTo and Select constructors of SimplUtils.SimplCont.
      
      See Note [Avoid redundant simplification]
      fb982282
  32. 15 Sep, 2010 3 commits
  33. 14 Sep, 2010 1 commit
  34. 13 Sep, 2010 1 commit