This project is mirrored from 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. 08 Feb, 2017 23 commits
  2. 07 Feb, 2017 7 commits
    • Siddhanathan Shanmugam's avatar
    • Daniel Gröber (dxld)'s avatar
      Docs: Fix typo in glasgow_exts.rst · 078beea9
      Daniel Gröber (dxld) authored
    • Simon Peyton Jones's avatar
      Another improvement to SetLevels · b8f58d79
      Simon Peyton Jones authored
      In my recent commit
         commit 432f952e
         Float unboxed expressions by boxing
      I changed how float_me in lvlMFE worked.  That was right, but
      it exposed another bug: an error expression wasn't getting floated
      as it should from a case alternative.  And that led to a collection
      of minor improvements
      * I found a much better way to cast it, by using lvlFloatRhs for
        top-level bindinds as well as nested ones, which is
          (a) more consistent and
          (b) works correctly.
        See Note [Floating from a RHS]
      * I also found some delicacy in the "floating to the top" stuff, so I
        greatly elaborated the Note [Floating to the top].
      * I simplified the "bottoming-float" stuff; the change is in the treatment
        of bottoming lambdas (\x y. error blah), where we now float the
        (error blah) part instead of the whole lambda (which risks just making
        duplicate lambdas.  See Note [Bottoming floats], esp (2).
      Perf effects are minor.
      * perf/compiler/T13056 improved sligtly (about 2%) in compiler
        allocations. Also T9233 improved by 1%.  I'm not sure why.
      * Some small nofib changes:
          - Generally some very small reductions in run-time
            allocation, except k-nucleotide, which halves for some
            reason.  (I did try to look but it's a big complicated
            function and it was far from obvious.  Had it been a loss
            I would have looked harder!
      NB: there's a nearby patch "Do not inline bottoming things" that could
      also be responsible for either or both.  I didn't think it was worth
      more testing to distinguish.
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
                 grep          +0.1%     -0.2%      0.00      0.00     +0.0%
               mandel          -0.1%     -1.4%      0.13      0.13     +0.0%
         k-nucleotide          +0.1%    -51.6%     -1.0%     -1.0%     +0.0%
                  Min          -0.3%    -51.6%     -9.4%     -9.1%     -4.0%
                  Max          +0.2%     +0.0%    +31.8%    +32.7%     +0.0%
       Geometric Mean          -0.0%     -0.8%     +1.4%     +1.4%     -0.1%
    • Simon Peyton Jones's avatar
      Comments only · f77e99bb
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Do not inline bottoming things · a0174d22
      Simon Peyton Jones authored
      If a function seems small, worker/wrapper won't split it; instead
      it turns it into an INLINE function.
      But if it's a /bottoming/ function that's a bad idea.  We want
      don't want to inline bottoming functions unless they are /really/
      small (smaller than the call itself) and that's handled by a
      different branch in certainlyWillInline.
      So this patch adds a not-bottom test to the UnfIfGoodArgs case of
      No big perf effect, but this will tend to keep error code out of
      functions, and hence make them a bit more likely to inline.
      I fell over this when fiddling with #13144
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 17ae5e79
      Gabor Greif authored
    • David Feuer's avatar
      Derive <$ · 2219c8cd
      David Feuer authored
      Using the default definition of `<$` for derived `Functor`
      instance is very bad for recursive data types. Derive
      the definition instead.
      Fixes #13218
      Reviewers: austin, bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, thomie
      Differential Revision:
  3. 06 Feb, 2017 10 commits
    • Ryan Scott's avatar
      Remove unnecessary use of -DGENERICS flag · a28a5521
      Ryan Scott authored
      This flag was only needed for old versions of binary, and now that we've
      upgraded to binary-, it is no longer necessary.
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 4aae1918
      Gabor Greif authored
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 2dff54b3
      Gabor Greif authored
    • Eric Seidel's avatar
      Do Worker/Wrapper for NOINLINE things · b572aadb
      Eric Seidel authored
      Disabling worker/wrapper for NOINLINE things can cause unnecessary
      reboxing of values. Consider
          {-# NOINLINE f #-}
          f :: Int -> a
          f x = error (show x)
          g :: Bool -> Bool -> Int -> Int
          g True  True  p = f p
          g False True  p = p + 1
          g b     False p = g b True p
      the strictness analysis will discover f and g are strict, but because f
      has no wrapper, the worker for g will rebox p. So we get
          $wg x y p# =
            let p = I# p# in  -- Yikes! Reboxing!
            case x of
              False ->
                case y of
                  False -> $wg False True p#
                  True -> +# p# 1#
              True ->
                case y of
                  False -> $wg True True p#
                  True -> case f p of { }
          g x y p = case p of (I# p#) -> $wg x y p#
      Now, in this case the reboxing will float into the True branch, an so
      the allocation will only happen on the error path. But it won't float
      inwards if there are multiple branches that call (f p), so the reboxing
      will happen on every call of g. Disaster.
      Solution: do worker/wrapper even on NOINLINE things; but move the
      NOINLINE pragma to the worker.
      Test Plan: make test TEST="13143"
      Reviewers: simonpj, bgamari, dfeuer, austin
      Reviewed By: simonpj, bgamari
      Subscribers: dfeuer, thomie
      Differential Revision:
    • Ben Gamari's avatar
    • lukemaurer's avatar
      Fixes for OccurAnal bugs (#13221) · 795bc49c
      lukemaurer authored
      - OccurAnal: When checking tail calls, count rule's LHS args, not bndrs
      Pretty obvious error in retrospect:
      let $sj = \y ys -> ...
          {-# RULES "SC:j" forall y ys. j (y:ys) = $sj y ys #-}
          j = \xs -> ...
          in ...
      A jump on the RHS of a rule for a join point is only okay if the rule's
      LHS is
      saturated - in this case, since the LHS is j (y:ys) and j takes one
      both j and $sj can become join points. See Note [Rules and join points]
      OccurAnal. By mistake, OccAnal was counting the rule's binders (y and
      ys) rather
      than the args in its LHS, so $sj wasn't being made a join point.
      - Don't zap tail calls in unfoldings
      This was causing T7796 to squeal about join points not being
      Reviewers: bgamari, austin
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision:
    • Takenobu Tani's avatar
      Fix broken link of GHC.RTS.Flags · 563148cd
      Takenobu Tani authored
      There ware broken link to GHC User's Guide.
      * libraries/base/GHC/RTS/Flags.hsc
       - runtime-control.html -> runtime_control.html
      Reviewers: bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision:
    • Takenobu Tani's avatar
      Fix comment (old file names '.hc' ) in libraries/ · 26f5e60b
      Takenobu Tani authored
      There ware some old file names (.hc, ...) at comments.
      * libraries/base/GHC/IO.hs
        - StgMiscClosures.hc -> StgStartup.cmm
        - Exceptions.hc -> Exception.cmm
        - Schedule.c -> RaiseAsync.c
      A comment of `(un)?blockAsyncExceptionszh_fast` in IO.hs may be old.
      Since I don't understand it, I have not modified it yet.
      Reviewers: mpickering, bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision:
    • Matthew Pickering's avatar
      Don't return empty initial uncovered set for an unsat context · adb565aa
      Matthew Pickering authored
      Previously when the checker encountered an unsatisfiable term of type
      context it would return an empty initial uncovered set. This caused all
      pattern matches in the context to be reported as redudant.
      This is arguably correct behaviour as they will never be reached but it
      is better to recover and provide accurate warnings for these cases to
      avoid error cascades. It would perhaps be better to report an error to
      the user about an inacessible branch but this is certainly better than
      many confusing redundant match warnings.
      Reviewers: gkaracha, austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision:
    • rwbarton's avatar
      Don't replace type family instances with the same LHS in GHCi (#7102) · 0abe7361
      rwbarton authored
      This fixes the easy part of #7102 by removing the logic that lets the
      user replace a type family instance with a new one with the same LHS.
      As discussed on that ticket, this is unsound in general. Better to have
      the user redefine the type family from scratch.
      The example from comment:7 involving loading modules into ghci is not
      fixed yet; it actually doesn't rely on the instances having the same LHS.
      This commit adds an expect_broken test for that example as well.
      Test Plan: T7102a for the fix; T7102 is the test not fixed yet
      Reviewers: dfeuer, austin, bgamari, goldfire
      Reviewed By: dfeuer
      Subscribers: dfeuer, thomie
      Differential Revision: