1. 12 Jan, 2017 1 commit
  2. 10 Jan, 2017 1 commit
  3. 06 Jan, 2017 3 commits
    • Ryan Scott's avatar
      Add performance test for #13056 · 50881100
      Ryan Scott authored
      This performance regression was fixed by commit
      517d03e4 (#12234). Let's add a performance test
      to ensure that it doesn't break again.
      50881100
    • Simon Peyton Jones's avatar
      Fix the implementation of the "push rules" · b4f2afe7
      Simon Peyton Jones authored
      Richard pointed out (comment:12 of Trac #13025) that my
      implementation of the coercion "push rules", newly added
      in exprIsConAppMaybe by commit b4c3a668, wasn't quite right.
      
      But in fact that means that the implementation of those same
      rules in Simplify.simplCast was wrong too.
      
      Hence this commit:
      
      * Refactor the push rules so they are implemented in just
        one place (CoreSubst.pushCoArgs, pushCoTyArg, pushCoValArg)
        The code in Simplify gets simpler, which is nice.
      
      * Fix the bug that Richard pointed out (to do with hetero-kinded
        coercions)
      
      Then compiler performance worsened, which led mt do discover
      two performance bugs:
      
      * The smart constructor Coercion.mkNthCo didn't have a case
        for ForAllCos, which meant we stupidly build a complicated
        coercion where a simple one would do
      
      * In OptCoercion there was one place where we used CoherenceCo
        (the data constructor) rather than mkCoherenceCo (the smart
        constructor), which meant that the the stupid complicated
        coercion wasn't optimised away
      
      For reasons I don't fully understand, T5321Fun did 2% less compiler
      allocation after all this, which is good.
      b4f2afe7
    • Simon Peyton Jones's avatar
      Avoid exponential blowup in FamInstEnv.normaliseType · 3540d1e1
      Simon Peyton Jones authored
      Trac #13035 showed up a nasty case where we took exponentially
      long to normalise a (actually rather simple) type.  Fortunately
      it was easy to fix: see Note [Normalisation and type synonyms].
      3540d1e1
  4. 23 Dec, 2016 2 commits
  5. 21 Dec, 2016 1 commit
  6. 15 Dec, 2016 1 commit
  7. 09 Dec, 2016 1 commit
    • Sylvain Henry's avatar
      Scrutinee Constant Folding · d3b546b1
      Sylvain Henry authored
      This patch introduces new rules to perform constant folding through
      case-expressions.
      
      E.g.,
      ```
      case t -# 10# of _ {  ===> case t of _ {
               5#      -> e1              15#     -> e1
               8#      -> e2              18#     -> e2
               DEFAULT -> e               DEFAULT -> e
      ```
      
      The initial motivation is that it allows "Merge Nested Cases"
      optimization to kick in and to further simplify the code
      (see Trac #12877).
      
      Currently we recognize the following operations for Word# and Int#: Add,
      Sub, Xor, Not and Negate (for Int# only).
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2762
      
      GHC Trac Issues: #12877
      d3b546b1
  8. 05 Dec, 2016 2 commits
    • Simon Peyton Jones's avatar
      Use isFamFreeTyCon now we have it · e9123102
      Simon Peyton Jones authored
      Refactoring only
      e9123102
    • Simon Peyton Jones's avatar
      Fix an asymptotic bug in the occurrence analyser · 517d03e4
      Simon Peyton Jones authored
      Trac #12425 and #12234 showed up a major and long-standing
      bug in the occurrence analyser, whereby it could generate
      explonentially large program!
      
      There's a lot of commentary on #12425; and it's all described
      in Note [Loop breakers, node scoring, and stability]
      
      I did quite a lot of refactoring to make the code comprehensibe
      again (its structure had bit-rotted rather), so the patch
      looks bigger than it really is.
      
      Hurrah!
      
      I did a nofib run to check that I hadn't inadertently ruined
      anything:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                fluid          -0.3%     -1.5%      0.01      0.01     +0.0%
               parser          -0.9%     +0.6%      0.04      0.04     +0.0%
               prolog          -0.1%     +1.2%      0.00      0.00     +0.0%
      
      --------------------------------------------------------------------------------
                  Min          -0.9%     -1.5%     -8.6%     -8.7%     +0.0%
                  Max          +0.1%     +1.2%     +7.7%     +7.8%     +2.4%
       Geometric Mean          -0.2%     -0.0%     -0.2%     -0.3%     +0.0%
      
      I checked what happened in 'prolog'.  It seems that we have a
      recursive data structure something like this
      
         f :: [blah]
         f x = build (\cn.  ...g...  )
      
         g :: [blah2]
         g y = ....(foldr k z (f y))....
      
      If we inline 'f' into 'g' we get better fusion than the other
      way round, but we don't have any way to spot that at the moment.
      (I wonder if we could do worker/wrapper for functions returning
      a 'build'?)  It was happening before by a fluke.
      
      Anyway I decided to accept this; it's relatively rare I think.
      517d03e4
  9. 25 Nov, 2016 2 commits
    • Simon Peyton Jones's avatar
      Perf improvements in T6048, T10547 · 90a65ad0
      Simon Peyton Jones authored
      I think this wave of commits just made these two a little better;
      they must have been close to the threshold before.
      90a65ad0
    • Simon Peyton Jones's avatar
      Another major constraint-solver refactoring · 1eec1f21
      Simon Peyton Jones authored
      This patch takes further my refactoring of the constraint
      solver, which I've been doing over the last couple of months
      in consultation with Richard.
      
      It fixes a number of tricky bugs that made the constraint
      solver actually go into a loop, including
      
        Trac #12526
        Trac #12444
        Trac #12538
      
      The main changes are these
      
      * Flatten unification variables (fmvs/fuvs) appear on the LHS
        of a tvar/tyvar equality; thus
                 fmv ~ alpha
        and not
                 alpha ~ fmv
      
        See Note [Put flatten unification variables on the left]
        in TcUnify.  This is implemented by TcUnify.swapOverTyVars.
      
      * Don't reduce a "loopy" CFunEqCan where the fsk appears on
        the LHS:
            F t1 .. tn ~ fsk
        where 'fsk' is free in t1..tn.
        See Note [FunEq occurs-check principle] in TcInteract
      
        This neatly stops some infinite loops that people reported;
        and it allows us to delete some crufty code in reduce_top_fun_eq.
        And it appears to be no loss whatsoever.
      
        As well as fixing loops, ContextStack2 and T5837 both terminate
        when they didn't before.
      
      * Previously we generated "derived shadow" constraints from
        Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly
        generate a derived shadow from the same Wanted.
      
        A big change in this patch is to have two kinds of Wanteds:
           [WD] behaves like a pair of a Wanted and a Derived
           [W]  behaves like a Wanted only
        See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh
        field of a Wanted.
      
        This turned out to be a lot simpler.  A [WD] gets split into a
        [W] and a [D] in TcSMonad.maybeEmitShaodow.
      
        See TcSMonad Note [The improvement story and derived shadows]
      
      * Rather than have a separate inert_model in the InertCans, I've
        put the derived equalities back into inert_eqs.  We weren't
        gaining anything from a separate field.
      
      * Previously we had a mode for the constraint solver in which it
        would more aggressively solve Derived constraints; it was used
        for simplifying the context of a 'deriving' clause, or a 'default'
        delcaration, for example.
      
        But the complexity wasn't worth it; now I just make proper Wanted
        constraints.  See TcMType.cloneWC
      
      * Don't generate injectivity improvement for Givens; see
        Note [No FunEq improvement for Givens] in TcInteract
      
      * solveSimpleWanteds leaves the insolubles in-place rather than
        returning them.  Simpler.
      
      I also did lots of work on comments, including fixing Trac #12821.
      1eec1f21
  10. 10 Nov, 2016 1 commit
  11. 26 Oct, 2016 1 commit
  12. 25 Oct, 2016 1 commit
  13. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Accept 20% dedgradation in Trac #5030 compile time · 1f09b246
      Simon Peyton Jones authored
      In commit
      
        31621b12 * A collection of type-inference refactorings.
      
      I fixed a bug in the on-the-fly unifier.  Usually the
      on-the-fly unifier (TcUnify) defers type function
      applications to the constraint solver.  But in one situation
      it inconsistently did not defer, so a unification happened
      without reducing a type function.  By a fluke this makes
      T5030 (specifcially the definition of cnst) much better.
      
      It turns out that consistently non-deferring type functions
      makes the test for #3064 go bad.  So somehow the current,
      inconsistent situation was an accidental sweet spot.
      
      But it's a horrible sweet spot, relying on what was essentially
      a bug.  So I've accepted the worsening (it's an exotic case),
      and opened #12724 to deal with the underlying cause.
      1f09b246
  14. 14 Oct, 2016 1 commit
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  15. 12 Oct, 2016 1 commit
  16. 10 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improved stats for Trac #1969 · cc5ca21b
      Simon Peyton Jones authored
      With my latest commits
      
        76a5477b Move zonking out of tcFamTyPats
        b255ae7b Orient improvement constraints better
      
      perf has improved slightly for T1969:
      
      allocs:    733M -> 26M
      residency: 43M  -> 41M
      
      I don't know exactly why, but hey, it's good
      cc5ca21b
  17. 24 Sep, 2016 1 commit
    • Joachim Breitner's avatar
      Replace INLINEABLE by INLINABLE (#12613) · 68f72f10
      Joachim Breitner authored
      as the latter is the official, correct spelling, and the former just a
      misspelling accepted by GHC.
      
      Also document in the user’s guide that the alternative spelling is
      accepted
      
      This commit was brough to you by HIW 2016.
      68f72f10
  18. 23 Sep, 2016 1 commit
    • Richard Eisenberg's avatar
      Fix #12442. · 9766b0c8
      Richard Eisenberg authored
      The problem is described in the ticket.
      
      This patch adds new variants of the access points to the pure
      unifier that allow unification of types only when the caller
      wants this behavior. (The unifier used to also unify kinds.)
      This behavior is appropriate when the kinds are either already
      known to be the same, or the list of types provided are a
      list of well-typed arguments to some type constructor. In the
      latter case, unifying earlier types in the list will unify the
      kinds of any later (dependent) types.
      
      At use sites, I went through and chose the unification function
      according to the criteria above.
      
      This patch includes some modest performance improvements as we
      are now doing less work.
      9766b0c8
  19. 05 Sep, 2016 1 commit
    • Ryan Scott's avatar
      Derive the Generic instance in perf/compiler/T5642 · 34010dbe
      Ryan Scott authored
      Summary:
      For some inexplicable reason, the `Generic` instance in
      `perf/compiler/T5642` is written out entirely by hand. This is not only
      strange, since Trac #5642 is about derived `Generic` instances, but it also
      annoying to maintain, since it requires manually changing a bunch of code
      whenever the algorithm behind `deriving Generic` changes. (See D2304 for a
      recent example of this.)
      
      It seems more sensible to just derive the `Generic` instance. It shifts the
      goalposts of what allocations we're measuring a bit, since we no longer have
      to parse a large amount of code (and as a knock-on effect, the allocations go
      down a bit). But I think this program is morally equivalent to what we were
      benchmarking before, so it's not too unreasonable to change.
      
      Test Plan: make test TEST=T5642
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D2511
      
      GHC Trac Issues: #5642
      34010dbe
  20. 01 Sep, 2016 2 commits
  21. 31 Aug, 2016 1 commit
  22. 21 Aug, 2016 1 commit
  23. 17 Aug, 2016 1 commit
  24. 07 Aug, 2016 1 commit
  25. 05 Aug, 2016 1 commit
  26. 26 Jul, 2016 1 commit
  27. 16 Jul, 2016 2 commits
  28. 24 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of instance defaults · d2958bd0
      Simon Peyton Jones authored
      In an instance declaration when you don't specify the code for a
      method, GHC fills in from the default binding in the class.
      The type of the default method can legitmiately be ambiguous ---
      see Note [Default methods in instances] in TcInstDcls --- so
      typechecking it can be tricky.
      
      Trac #12220 showed that although we were dealing with that ambiguity
      for /vanilla/ default methods, we were not doing so for /generic/
      default methods.  Moreover we were dealing with it clumsily, by
      generating post-typechecked code.
      
      This patch fixes the bug AND deletes code!  We now use the same code
      path for both vanilla and generic default methods; and generate
      /pre-typechecked/ code in both cases.  The key trick is that we can use
      Visible Type Application to deal with the ambiguity, which wasn't
      possible before.  Hooray.
      
      There is a small hit to performance in compiler/perf/T1969 which
      consists of nothing BUT instance declarations with several default
      methods to fill, which we now have to typecheck. The actual hit is
      from 724 -> 756 or 4% in that extreme example.  Real world programs
      have vastly fewer instance decls.
      d2958bd0
  29. 18 Jun, 2016 2 commits
    • Ryan Scott's avatar
      Refactor derived Generic instances to reduce allocations · 9649fc0a
      Ryan Scott authored
      Previously, derived implementations of `to`/`from` in `Generic`
      instances were wastefully putting extra `M1`s in every case, which led
      to an O(n) increase in the number of coercions, resulting in a slowdown
      during the typechecker phase.
      
      This factors out the common `M1` in every case of a `to`/`from`
      definition so that the typechecker has far fewer coercions to deal with.
      For a datatype with 300 constructors, this change has been observed to
      save almost 3 seconds of compilation time.
      
      This is one step towards coming up with a solution for #5642.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: basvandijk, carter, thomie, osa1
      
      Differential Revision: https://phabricator.haskell.org/D2304
      
      GHC Trac Issues: #5642
      9649fc0a
    • Ryan Scott's avatar
      Add Bifoldable and Bitraversable to base · 270d545d
      Ryan Scott authored
      This adds `Data.Bifoldable` and `Data.Bitraversable` from the
      `bifunctors` package to `base`, completing the migration started in
      D336.  This is fairly straightforward, although there were a suprising
      amount of reinternal organization in `base` that was needed for this to
      happen:
      
      * `Data.Foldable`, `Data.Traversable`, `Data.Bifoldable`, and
        `Data.Bitraversable` share some nonexported datatypes (e.g., `StateL`,
        `StateR`, `Min`, `Max`, etc.) to implement some instances. To avoid
        code duplication, I migrated this internal code to a new hidden
        module, `Data.Functor.Utils` (better naming suggestions welcome).
      
      * `Data.Traversable` and `Data.Bitraversable` also make use of an
        identity newtype, so I modified them to use
        `Data.Functor.Identity.Identity`. This has a ripple effect on several
        other modules, since I had to move instances around in order to avoid
        dependency cycles.
      
      Fixes #10448.
      
      Reviewers: ekmett, hvr, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2284
      
      GHC Trac Issues: #9682, #10448
      270d545d
  30. 05 Jun, 2016 1 commit
  31. 15 May, 2016 1 commit
    • Ömer Sinan Ağacan's avatar
      Fix a performance issue with -fprint-expanded-synonyms · e4834edf
      Ömer Sinan Ağacan authored
      The type synonym expander was doing redundant work by looking at same
      types again and again. This patch fixes the loop code when both of the
      types can be expanded, to do `O(min(n, m))` comparisons and `O(n + m)`
      expansions, where `n` is expansions of the first type and `m` is
      expansions of the second type.
      
      Reported by sjcjoosten in T10547.
      
      Test Plan:
      Added a regression test that was taking several minutes to type check
      before this patch.
      
      Reviewers: bgamari, simonpj, austin, ezyang
      
      Reviewed By: bgamari, simonpj, austin, ezyang
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2198
      
      GHC Trac Issues: #10547
      e4834edf
  32. 12 May, 2016 1 commit
    • Ryan Scott's avatar
      Make Generic1 poly-kinded · b8e25651
      Ryan Scott authored
      This generalizes the `Generic1` typeclass to be of kind `k -> *`, and
      this also makes the relevant datatypes and typeclasses in `GHC.Generics`
      poly-kinded. If `PolyKinds` is enabled, `DeriveGeneric` derives
      `Generic1` instances such that they use the most general kind possible.
      Otherwise, deriving `Generic1` defaults to make an instance where the
      argument is of kind `* -> *` (the current behavior).
      
      Fixes #10604. Depends on D2117.
      
      Test Plan: ./validate
      
      Reviewers: kosmikus, dreixel, goldfire, austin, hvr, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie, ekmett
      
      Differential Revision: https://phabricator.haskell.org/D2168
      
      GHC Trac Issues: #10604
      b8e25651