1. 29 Dec, 2011 1 commit
  2. 28 Nov, 2011 1 commit
    • dimitris's avatar
      This patch includes: · f3183d9a
      dimitris authored
      0) Typo in panic message.
      1) prioritization of equalities over family equalities in the worklists.
      2) rewriting of inert substitutions and solveds on-the-spot instead of
         kicking them out in the inerts. This required a monadic map over
         substitutions hence the modifications in UniqFM.
      3) Just comments and removing stale commented code.
      4) Useful SCC for simplifyInfer.
      5) Making CoreStats outputable.
  3. 22 Nov, 2011 2 commits
  4. 16 Nov, 2011 2 commits
  5. 15 Nov, 2011 1 commit
  6. 11 Nov, 2011 2 commits
  7. 04 Nov, 2011 1 commit
  8. 02 Nov, 2011 2 commits
    • Simon Marlow's avatar
      remove tabs again · 515728a3
      Simon Marlow authored
    • Simon Marlow's avatar
      Overhaul of infrastructure for profiling, coverage (HPC) and breakpoints · 7bb0447d
      Simon Marlow authored
      User visible changes
      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
      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
      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.
      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)
  9. 27 Sep, 2011 2 commits
  10. 17 Sep, 2011 1 commit
    • Ian Lynagh's avatar
      Improve the handling of Integer literals · 1e87c0a6
      Ian Lynagh authored
      LitInteger now carries around the id of mkInteger, which it uses
      to construct the core to build Integer literals. This way we don't
      have to build in info about lots of Ids.
      We also no longer have any special-casing for integer-simple, so
      there is less code involved.
  11. 13 Sep, 2011 1 commit
    • Ian Lynagh's avatar
      change how Integer's are handled in Core · fdac48f3
      Ian Lynagh authored
      We now treat them as literals until CorePrep, when we finally
      convert them into the real Core representation. This makes it a lot
      simpler to implement built-in rules on them.
  12. 07 Sep, 2011 1 commit
  13. 05 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Fix two bugs in caes-floating (fixes Trac #5453) · bd6f5de7
      Simon Peyton Jones authored
      The problem is documented in the ticket.  The patch
      does two things
      1. Make exprOkForSpeculation return False for a non-exhaustive case
      2. In SetLevels.lvlExpr, look at the *result* scrutinee, not the
         *input* scrutinee, when testing for evaluated-ness
  14. 03 Aug, 2011 1 commit
  15. 21 Jul, 2011 1 commit
    • Simon Peyton Jones's avatar
      Change loop breaker terminology · e815d4b1
      Simon Peyton Jones authored
      We used to have "loop breaker" and "non-rule loop breaker", but
      the unqualified version in particualr was pretty confusing.  So
      now we have "strong loop breaker" and "weak loop breaker";
      comments in BasicTypes and OccurAnal.
  16. 20 Jul, 2011 1 commit
  17. 30 Jun, 2011 1 commit
  18. 22 Jun, 2011 2 commits
    • Simon Peyton Jones's avatar
      Comments and layout · e8fe3a12
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Remove "silent superclass parameters" · a9d48fd9
      Simon Peyton Jones authored
      We introduced silent superclass parameters as a way to avoid
      superclass loops, but we now solve that problem a different
      way ("derived" superclass constraints carry no evidence). So
      they aren't needed any more.
      Apart from being a needless complication, they broke DoCon.
      Admittedly in a very obscure way, but still the result is
      hard to explain. To see the details see Trac #5051, with
      test case typecheck/should_compile/T5051.  (The test is
      nice and small!)
  19. 11 Jun, 2011 1 commit
  20. 24 May, 2011 1 commit
  21. 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
  22. 31 Mar, 2011 1 commit
  23. 15 Feb, 2011 3 commits
  24. 14 Feb, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Fix exprIsDupable · 34456244
      simonpj@microsoft.com authored
      It turns out that exprIsDupable would return True for an expression of
      *arbitrary* size, provide it was a nested bunch of applications in
      which no function had more than three arguments.  That was never the
      intention, and could give rise to massive code duplication.  
      This patch makes it much less aggressive.
  25. 01 Feb, 2011 1 commit
  26. 25 Jan, 2011 2 commits
  27. 22 Dec, 2010 1 commit
  28. 21 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Add a simple arity analyser · 1d7a3cf3
      simonpj@microsoft.com authored
      I've wanted to do this for ages, but never gotten around to
      it.  The main notes are in Note [Arity analysis] in SimplUtils.
      The motivating example for arity analysis is this:
        f = \x. let g = f (x+1)
                in \y. ...g...
      What arity does f have?  Really it should have arity 2, but a naive
      look at the RHS won't see that.  You need a fixpoint analysis which
      says it has arity "infinity" the first time round.
      This makes things more robust to the way in which you write code.  For
      example, see Trac #4474 which is fixed by this change.
      Not a huge difference, but worth while:
              Program           Size    Allocs   Runtime   Elapsed
                  Min          -0.4%     -2.2%    -10.0%    -10.0%
                  Max          +2.7%     +0.3%     +7.1%     +6.9%
       Geometric Mean          -0.3%     -0.2%     -2.1%     -2.2%
      I don't really believe the runtime numbers, because the machine was
      busy, but the...
  29. 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 InstE...
  30. 23 Oct, 2010 1 commit
  31. 29 Sep, 2010 1 commit