1. 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
  2. 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
  3. 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
  4. 01 Sep, 2016 2 commits
  5. 31 Aug, 2016 1 commit
  6. 21 Aug, 2016 1 commit
  7. 17 Aug, 2016 1 commit
  8. 07 Aug, 2016 1 commit
  9. 05 Aug, 2016 1 commit
  10. 26 Jul, 2016 1 commit
  11. 16 Jul, 2016 2 commits
  12. 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
  13. 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
  14. 05 Jun, 2016 1 commit
  15. 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
  16. 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
  17. 15 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve TcFlatten.flattenTyVar · a7ee2d4c
      Simon Peyton Jones authored
      This patch tides up the structure, simplifying FlattenTvResult.
      
      It also replaces a use of zonkTcType (which I hated) with
      coercionKind, in that same function.  Happily, the result is
      little faster, maybe even a percentage point or two, which is
      a lot for a compiler.
      
      This also removes the line
         || not (map binderVisibility bndrs1 == map binderVisibility bndrs2)
      from TcCanonical.can_eq_nc', in the ForAllTy/ForAllTy case.
      
      Why? Becuase I can't see why binder-visiblity should matter, and
      when we use coercionKind instead of zonkTcType in flattenTyVar,
      this case pops up and rejects a program that should pass.  I did
      discuss this with Richard.
      a7ee2d4c
  18. 14 Apr, 2016 1 commit
    • Joachim Breitner's avatar
      Add a final demand analyzer run right before TidyCore · f4fd98c7
      Joachim Breitner authored
      in order to have precise used-once information in the exported
      strictness signatures, as well as precise used-once information on
      thunks. This avoids the bad effects of #11731.
      
      The subsequent worker-wrapper pass is responsible for removing the
      demand environment part of the strictness signature. It does not run
      after the final demand analyzer pass, so remove this also in CoreTidy.
      
      The subsequent worker-wrapper pass is also responsible for removing
      used-once-information from the demands and strictness signatures, as
      these might not be preserved by the simplifier. This is _not_ done by
      CoreTidy, because we _do_ want this information, as produced by the last
      round of the demand analyzer, to be available to the code generator.
      
      Differential Revision: https://phabricator.haskell.org/D2073
      f4fd98c7
  19. 08 Apr, 2016 1 commit
  20. 07 Apr, 2016 3 commits
  21. 06 Apr, 2016 2 commits
  22. 24 Mar, 2016 1 commit
    • Ben Gamari's avatar
      Defer inlining of Eq for primitive types · 0bd0c31e
      Ben Gamari authored
      Summary:
      This is one solution to #11688, wherein (==) was inlined to soon
      defeating a rewrite rule provided by bytestring. Since the RHSs of Eq's
      methods are simple, there is little to be gained and much to be lost by
      inlining them early.
      
      For instance, the bytestring library provides,
      
      ```lang=haskell
      break :: (Word8 -> Bool) -> ByteString -> (ByteString, ByteString)
      breakByte :: Word8 -> ByteString -> (ByteString, ByteString)
      ```
      
      and a rule
      
      ```
      forall x. break ((==) x) = breakByte x
      ```
      
      since `breakByte` implments an optimized version of `break (== x)` for
      known `x :: Word8`. If we allow `(==)` to be inlined too early, we will
      prevent this rule from firing. This was the cause of #11688.
      
      This patch just defers the `Eq` methods, although it's likely worthwhile
      giving `Ord` this same treatment. This regresses compiler allocations
      for T9661 by about 8% due to the additional inlining that we now require
      the simplifier to perform.
      
      Updates the `bytestring` submodule to include updated rewrite rules
      which match on `eqWord8` instead of `(==)`.
      
      Test Plan:
       * Validate, examine performance impact
      
      Reviewers: simonpj, hvr, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1980
      
      GHC Trac Issues: #11688
      0bd0c31e
  23. 21 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Prevent eager unification with type families. · 3e1b8824
      eir@cis.upenn.edu authored
      See Note [Prevent unification with type families]
      in TcUnify for the details.
      3e1b8824
    • eir@cis.upenn.edu's avatar
      Add two small optimizations. (#11196) · 0706a103
      eir@cis.upenn.edu authored
      - Optimize zonking * to avoid allocation.
      - Try to avoid looking at the free variables of a type in the
        pure unifier. We need look at the variables only in the case
        of a forall.
      
      The performance results updates included in this also include
      a regression, but the regression is not due to this patch. When
      validating previous patches, the test case failed, but I was
      unable to reproduce outside of validation, so I let it go by, thinking
      the failure was spurious. Upon closer inspection, the perf number
      was right at the line, and the wibble between a valiation environment
      and a regular test run was enough to make the difference.
      0706a103
  24. 20 Mar, 2016 1 commit
  25. 15 Mar, 2016 1 commit
  26. 11 Mar, 2016 1 commit
    • Ben Gamari's avatar
      Bump allocations for T6048 · 7ba817c2
      Ben Gamari authored
      This occassionally fails with allocations a few tenths of a percent
      above threshold. Sadly there isn't a clear cause; it's likely just the
      result of gradual creep, further underscoring the need for more regular
      performance characterization.
      7ba817c2
  27. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  28. 09 Feb, 2016 1 commit
  29. 08 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Define tyConRolesRepresentational and use it · 489a9a3b
      Simon Peyton Jones authored
      tyConRolesRepresentational is just a version of tyConRolesX, but
      specialised for a Representational argument. Saves a bit of extra
      argument passing and pattern matching, and tyConRolesX was often
      called when we knew the argument role was Representational.
      
      Rather to my surprise this made the compiler allocate 5% less
      for tests T9872{b,c,d}.  At least I think it's this commit.
      Good thing, regardless.
      489a9a3b
  30. 04 Feb, 2016 1 commit
    • Georgios Karachalias's avatar
      Overhaul the Overhauled Pattern Match Checker · 28f951ed
      Georgios Karachalias authored
      Overhaul the Overhauled Pattern Match Checker
      
      * Changed the representation of Value Set Abstractions. Instead of
      using a prefix tree, we now use a list of Value Vector Abstractions.
      The set of constraints Delta for every Value Vector Abstraction is the
      oracle state so that we solve everything only once.
      
      * Instead of doing everything lazily, we prune at once (and in general
      everything is much stricter). Hence, an example written with pattern
      guards is checked in almost the same time as the equivalent with
      pattern matching.
      
      * Do not store the covered and the divergent sets at all. Since what we
      only need is a yes/no (does this clause cover anything? Does it force
      any thunk?) We just keep a boolean for each.
      
      * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`.
      Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should
      the default `n` be.
      
      * When a guard is for sure not going to contribute anything, we treat
      it as such: The oracle is not called and cases `CGuard`, `UGuard` and
      `DGuard` from the paper are not happening at all (the generation of a
      fresh variable, the unfolding of the pattern list etc.). his combined
      with the above seems to be enough to drop the memory increase for test
      T783 down to 18.7%.
      
      * Do not export function `dsPmWarn` (it is now called directly from
      within `checkSingle` and `checkMatches`).
      
      * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle
      does not handle type information so using `Id` was a waste of
      time/space.
      
      * Added testcases T11195, T11303b (data families) and T11374
      
      The patch addresses at least the following:
      Trac #11195, #11276, #11303, #11374, #11162
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, hvr, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1795
      28f951ed
  31. 27 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  32. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
  33. 17 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Fix tcTyClTyVars to handle SigTvs · ae86eb9f
      eir@cis.upenn.edu authored
      Previously, tcTyClTyVars required that the names of the LHsQTyVars
      matched up exactly with the names of the kind of the given TyCon.
      It now does a bit of matching up when necessary to relax this
      restriction.
      
      This commit enables a few tests that had previously been disabled.
      
      The shortcoming this addresses is discussed in #11203, but that
      ticket is not directly addressed here.
      
      Test case: polykinds/SigTvKinds, perf/compiler/T9872d
      ae86eb9f