This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 10 Apr, 2015 1 commit
  2. 07 Apr, 2015 1 commit
  3. 30 Mar, 2015 1 commit
    • Joachim Breitner's avatar
      Refactor the story around switches (#10137) · de1160be
      Joachim Breitner authored
      This re-implements the code generation for case expressions at the Stg →
      Cmm level, both for data type cases as well as for integral literal
      cases. (Cases on float are still treated as before).
      
      The goal is to allow for fancier strategies in implementing them, for a
      cleaner separation of the strategy from the gritty details of Cmm, and
      to run this later than the Common Block Optimization, allowing for one
      way to attack #10124. The new module CmmSwitch contains a number of
      notes explaining this changes. For example, it creates larger
      consecutive jump tables than the previous code, if possible.
      
      nofib shows little significant overall improvement of runtime. The
      rather large wobbling comes from changes in the code block order
      (see #8082, not much we can do about it). But the decrease in code size
      alone makes this worthwhile.
      
      ```
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
                  Min          -1.8%      0.0%     -6.1%     -6.1%     -2.9%
                  Max          -0.7%     +0.0%     +5.6%     +5.7%     +7.8%
       Geometric Mean          -1.4%     -0.0%     -0.3%     -0.3%     +0.0%
      ```
      
      Compilation time increases slightly:
      ```
              -1 s.d.                -----            -2.0%
              +1 s.d.                -----            +2.5%
              Average                -----            +0.3%
      ```
      
      The test case T783 regresses a lot, but it is the only one exhibiting
      any regression. The cause is the changed order of branches in an
      if-then-else tree, which makes the hoople data flow analysis traverse
      the blocks in a suboptimal order. Reverting that gets rid of this
      regression, but has a consistent, if only very small (+0.2%), negative
      effect on runtime. So I conclude that this test is an extreme outlier
      and no reason to change the code.
      
      Differential Revision: https://phabricator.haskell.org/D720
      de1160be
  4. 23 Mar, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Do proper depth checking in the flattener to avoid looping. · c1edbdfd
      eir@cis.upenn.edu authored
      This implements (roughly) the plan put forward in comment:14:ticket:7788,
      fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079.
      There are some regressions w.r.t. GHC 7.8, but only with pathological type
      families (like F a = F a). This also (hopefully -- don't have a test case)
      fixes #10158. Unsolved problems include #10184 and #10185, which are both
      known deficiencies of the approach used here.
      
      As part of this change, the plumbing around detecting infinite loops has
      changed. Instead of -fcontext-stack and -ftype-function-depth, we now have
      one combined -freduction-depth parameter. Setting it to 0 disbales the
      check, which is now the recommended way to get (terminating) code to
      typecheck in releases. (The number of reduction steps may well change between
      minor GHC releases!)
      
      This commit also introduces a new IntWithInf type in BasicTypes
      that represents an integer+infinity. This type is used in a few
      places throughout the code.
      
      Tests in
        indexed-types/should_fail/T7788
        indexed-types/should_fail/T8550
        indexed-types/should_fail/T9554
        indexed-types/should_compile/T10079
        indexed-types/should_compile/T10139
        typecheck/should_compile/T10184  (expected broken)
        typecheck/should_compile/T10185  (expected broken)
      
      This commit also changes performance testsuite numbers, for the better.
      c1edbdfd
  5. 22 Jan, 2015 3 commits
  6. 20 Jan, 2015 1 commit
  7. 19 Jan, 2015 1 commit
  8. 08 Jan, 2015 1 commit
  9. 07 Jan, 2015 1 commit
    • Edward Z. Yang's avatar
      Compress TypeMap TrieMap leaves with singleton constructor. · da64ab53
      Edward Z. Yang authored
      Suppose we have a handful H of entries in a TrieMap, each with a very large
      key, size K. If you fold over such a TrieMap you'd expect time O(H). That would
      certainly be true of an association list! But with TrieMap we actually have to
      navigate down a long singleton structure to get to the elements, so it takes
      time O(K*H).  The point of a TrieMap is that you need to navigate to the point
      where only one key remains, and then things should be fast.
      
      This is a starting point: we can improve the patch by generalizing the
      singleton constructor so it applies to CoercionMap and CoreMap; I'll do this
      in a later commit.
      
      Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D606
      
      GHC Trac Issues: #9960
      da64ab53
  10. 06 Jan, 2015 1 commit
  11. 23 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Eliminate so-called "silent superclass parameters" · a6f0f5ab
      Simon Peyton Jones authored
      The purpose of silent superclass parameters was to solve the
      awkward problem of superclass dictinaries being bound to bottom.
      See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls
      
      Although the silent-superclass idea worked,
      
        * It had non-local consequences, and had effects even in Haddock,
          where we had to discard silent parameters before displaying
          instance declarations
      
        * It had unexpected peformance costs, shown up by Trac #3064 and its
          test case.  In monad-transformer code, when constructing a Monad
          dictionary you had to pass an Applicative dictionary; and to
          construct that you neede a Functor dictionary. Yet these extra
          dictionaries were often never used.  (All this got much worse when
          we added Applicative as a superclass of Monad.) Test T3064
          compiled *far* faster after silent superclasses were eliminated.
      
        * It introduced new bugs.  For example SilentParametersOverlapping,
          T5051, and T7862, all failed to compile because of instance overlap
          directly because of the silent-superclass trick.
      
      So this patch takes a new approach, which I worked out with Dimitrios
      in the closing hours before Christmas.  It is described in detail
      in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls.
      
      Seems to work great!
      
      Quite a bit of knock-on effect
      
       * The main implementation work is in tcSuperClasses in TcInstDcls
         Everything else is fall-out
      
       * IdInfo.DFunId no longer needs its n-silent argument
         * Ditto IDFunId in IfaceSyn
         * Hence interface file format changes
      
       * Now that DFunIds do not have silent superclass parameters, printing
         out instance declarations is simpler. There is tiny knock-on effect
         in Haddock, so that submodule is updated
      
       * I realised that when computing the "size of a dictionary type"
         in TcValidity.sizePred, we should be rather conservative about
         type functions, which can arbitrarily increase the size of a type.
         Hence the new datatype TypeSize, which has a TSBig constructor for
         "arbitrarily big".
      
       * instDFunType moves from TcSMonad to Inst
      
       * Interestingly, CmmNode and CmmExpr both now need a non-silent
         (Ord r) in a couple of instance declarations. These were previously
         silent but must now be explicit.
      
       * Quite a bit of wibbling in error messages
      a6f0f5ab
  12. 20 Dec, 2014 2 commits
  13. 19 Dec, 2014 1 commit
  14. 17 Dec, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Performance enhancements in TcFlatten. · 922168fd
      eir@cis.upenn.edu authored
      This commit fixes some performance regressions introduced by 0cc47eb9,
      adding more `Coercible` magic to the solver. See Note
      [flatten_many performance] in TcFlatten for more info.
      
      The improvements do not quite restore the old numbers. Given that
      the solver is really more involved now, I am accepting this regression.
      
      The way forward (I believe) would be to have *two* flatteners: one
      that deals only with nominal equalities and thus never checks roles,
      and the more general one. A nice design of keeping this performant
      without duplicating code eludes me, but someone else is welcome
      to take a stab.
      922168fd
  15. 11 Dec, 2014 2 commits
  16. 10 Dec, 2014 2 commits
  17. 08 Dec, 2014 2 commits
    • Gabor Greif's avatar
      catch some recent typos · 2515686f
      Gabor Greif authored
      2515686f
    • Simon Peyton Jones's avatar
      Revise the inert-set invariants again · 1d44261c
      Simon Peyton Jones authored
      In particular this patch
      
      - Accepts that rewriting with the inert CTyEqCans should be done recursively
        (hence removing the Bool result from flattenTyVarOuter)
      
      - Refines the kick-out criterion, in paticular to avoid kick-out of (a -f-> ty)
        when f cannot rewrite f.  This is true of Wanteds and hence reduces kick-outs
        of Wanteds, perhaps by a lot
      
      This stuff is not fully documented because the details are still settling, but
      it's looking good.
      
      (And it validates.)
      
      This patch includes the testsuite wibbles.  perf/compiler/T5030 and
      T5837 both improve in bytes-allocated (by 11% and 13% resp), which is
      good.  I'm not sure which of today's short series of patches is
      responsible, nor do I mind much.  (One could find out if necessary.)
      1d44261c
  18. 03 Dec, 2014 1 commit
  19. 12 Nov, 2014 1 commit
  20. 07 Nov, 2014 1 commit
    • David Feuer's avatar
      Improve Applicative definitions · abba3812
      David Feuer authored
      Generally clean up things relating to Applicative and Monad in `GHC.Base`
      and `Control.Applicative` to make `Applicative` feel like a bit more of a
      first-class citizen rather than just playing second fiddle to `Monad`. Use
      `coerce` and GND to improve performance and clarity.
      
      Change the default definition of `(*>)` to use `(<$)`, in case the
      `Functor` instance optimizes that.
      
      Moreover, some manually written instances are made into compiler-derived
      instances.
      
      Finally, this also adds a few AMP-related laws to the `Applicative` docstring.
      
      NOTE: These changes result in a 13% decrease in allocation for T9020
      
      Reviewed By: ekmett, hvr
      
      Differential Revision: https://phabricator.haskell.org/D432
      abba3812
  21. 06 Nov, 2014 2 commits
  22. 05 Nov, 2014 1 commit
  23. 04 Nov, 2014 3 commits
  24. 27 Oct, 2014 1 commit
  25. 19 Oct, 2014 1 commit
    • Krzysztof Gogolewski's avatar
      Python 3 support, second attempt (Trac #9184) · d576fc38
      Krzysztof Gogolewski authored
      Summary:
      This is a fixup of https://phabricator.haskell.org/D233
      
      The only difference is in findTFiles (first commit), which
      previously broke Windows runner; now I translated literally
      instead attempting to improve it, and checked it works.
      
      Test Plan:
      I used validate under 2,3 on Linux and under 2 on msys2.
      On Windows I've seen a large number of failures, but they don't
      seem to be connected with the patch.
      
      Reviewers: hvr, simonmar, thomie, austin
      
      Reviewed By: austin
      
      Subscribers: thomie, carter, ezyang, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D310
      
      GHC Trac Issues: #9184
      d576fc38
  26. 13 Oct, 2014 6 commits