1. 18 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Type-indexed Typeable · 8fa4bf9a
      Ben Gamari authored
      This at long last realizes the ideas for type-indexed Typeable discussed in A
      Reflection on Types (#11011). The general sketch of the project is described on
      the Wiki (Typeable/BenGamari). The general idea is that we are adding a type
      index to `TypeRep`,
      
          data TypeRep (a :: k)
      
      This index allows the typechecker to reason about the type represented by the `TypeRep`.
      This index representation mechanism is exposed as `Type.Reflection`, which also provides
      a number of patterns for inspecting `TypeRep`s,
      
      ```lang=haskell
      pattern TRFun :: forall k (fun :: k). ()
                    => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                              (arg :: TYPE r1) (res :: TYPE r2).
                       (k ~ Type, fun ~~ (arg -> res))
                    => TypeRep arg
                    -> TypeRep res
                    -> TypeRep fun
      
      pattern TRApp :: forall k2 (t :: k2). ()
                    => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b)
                    => TypeRep a -> TypeRep b -> TypeRep t
      
      -- | Pattern match on a type constructor.
      pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a
      
      -- | Pattern match on a type constructor including its instantiated kind
      -- variables.
      pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a
      ```
      
      In addition, we give the user access to the kind of a `TypeRep` (#10343),
      
          typeRepKind :: TypeRep (a :: k) -> TypeRep k
      
      Moreover, all of this plays nicely with 8.2's levity polymorphism, including the
      newly levity polymorphic (->) type constructor.
      
      Library changes
      ---------------
      
      The primary change here is the introduction of a Type.Reflection module to base.
      This module provides access to the new type-indexed TypeRep introduced in this
      patch. We also continue to provide the unindexed Data.Typeable interface, which
      is simply a type synonym for the existentially quantified SomeTypeRep,
      
          data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep
      
      Naturally, this change also touched Data.Dynamic, which can now export the
      Dynamic data constructor. Moreover, I removed a blanket reexport of
      Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable
      now).
      
      We also add a kind heterogeneous type equality type, (:~~:), to
      Data.Type.Equality.
      
      Implementation
      --------------
      
      The implementation strategy is described in Note [Grand plan for Typeable] in
      TcTypeable. None of it was difficult, but it did exercise a number of parts of
      the new levity polymorphism story which had not yet been exercised, which took
      some sorting out.
      
      The rough idea is that we augment the TyCon produced for each type constructor
      with information about the constructor's kind (which we call a KindRep). This
      allows us to reconstruct the monomorphic result kind of an particular
      instantiation of a type constructor given its kind arguments.
      
      Unfortunately all of this takes a fair amount of work to generate and send
      through the compilation pipeline. In particular, the KindReps can unfortunately
      get quite large. Moreover, the simplifier will float out various pieces of them,
      resulting in numerous top-level bindings. Consequently we mark the KindRep
      bindings as noinline, ensuring that the float-outs don't make it into the
      interface file. This is important since there is generally little benefit to
      inlining KindReps and they would otherwise strongly affect compiler performance.
      
      Performance
      -----------
      
      Initially I was hoping to also clear up the remaining holes in Typeable's
      coverage by adding support for both unboxed tuples (#12409) and unboxed sums
      (#13276). While the former was fairly straightforward, the latter ended up being
      quite difficult: while the implementation can support them easily, enabling this
      support causes thousands of Typeable bindings to be emitted to the GHC.Types as
      each arity-N sum tycon brings with it N promoted datacons, each of which has a
      KindRep whose size which itself scales with N. Doing this was simply too
      expensive to be practical; consequently I've disabled support for the time
      being.
      
      Even after disabling sums this change regresses compiler performance far more
      than I would like. In particular there are several testcases in the testsuite
      which consist mostly of types which regress by over 30% in compiler allocations.
      These include (considering the "bytes allocated" metric),
      
       * T1969:  +10%
       * T10858: +23%
       * T3294:  +19%
       * T5631:  +41%
       * T6048:  +23%
       * T9675:  +20%
       * T9872a: +5.2%
       * T9872d: +12%
       * T9233:  +10%
       * T10370: +34%
       * T12425: +30%
       * T12234: +16%
       * 13035:  +17%
       * T4029:  +6.1%
      
      I've spent quite some time chasing down the source of this regression and while
      I was able to make som improvements, I think this approach of generating
      Typeable bindings at time of type definition is doomed to give us unnecessarily
      large compile-time overhead.
      
      In the future I think we should consider moving some of all of the Typeable
      binding generation logic back to the solver (where it was prior to
      91c6b1f5). I've opened #13261 documenting this
      proposal.
      8fa4bf9a
  2. 07 Feb, 2017 1 commit
    • 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: https://phabricator.haskell.org/D3072
      2219c8cd
  3. 06 Feb, 2017 1 commit
    • 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: https://phabricator.haskell.org/D3046
      b572aadb
  4. 01 Feb, 2017 1 commit
  5. 31 Jan, 2017 1 commit
    • Daniel Haraj's avatar
      Use top-level instances to solve superclasses where possible · 748b7974
      Daniel Haraj authored
      This patch introduces a new flag `-fsolve-constant-dicts` which makes the
      constraint solver solve super class constraints with available dictionaries if
      possible. The flag is enabled by `-O1`.
      
      The motivation of this patch is that the compiler can produce more efficient
      code if the constraint solver used top-level instance declarations to solve
      constraints that are currently solved givens and their superclasses. In
      particular, as it currently stands, the compiler imposes a performance penalty
      on the common use-case where superclasses are bundled together for user
      convenience. The performance penalty applies to constraint synonyms as
      well. This example illustrates the issue:
      
      ```
      {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, FlexibleContexts #-}
      module B where
      
      class M a b where m :: a -> b
      
      type C a b = (Num a, M a b)
      
      f :: C Int b => b -> Int -> Int
      f _ x = x + 1
      ```
      
      Output without the patch, notice that we get the instance for `Num Int` by
      using the class selector `p1`.
      
      ```
      f :: forall b_arz. C Int b_arz => b_arz -> Int -> Int
      f =
        \ (@ b_a1EB) ($d(%,%)_a1EC :: C Int b_a1EB) _ (eta1_B1 :: Int) ->
          + @ Int
            (GHC.Classes.$p1(%,%) @ (Num Int) @ (M Int b_a1EB) $d(%,%)_a1EC)
            eta1_B1
            B.f1
      ```
      
      Output with the patch, nicely optimised code!
      
      ```
      f :: forall b. C Int b => b -> Int -> Int
      f =
        \ (@ b) _ _ (x_azg :: Int) ->
          case x_azg of { GHC.Types.I# x1_a1DP ->
          GHC.Types.I# (GHC.Prim.+# x1_a1DP 1#)
          }
      ```
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: mpickering, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2714
      
      GHC Trac Issues: #12791, #5835
      748b7974
  6. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      The `clean_cmd` and `extra_clean` setup functions don't do anything.
      Remove them from .T files.
      
      Created using https://github.com/thomie/refactor-ghc-testsuite. This
      diff is a test for the .T-file parser/processor/pretty-printer in that
      repository.
      
          find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
      
      Tests containing inline comments or multiline strings are not modified.
      
      Preparation for #12223.
      
      Test Plan: Harbormaster
      
      Reviewers: austin, hvr, simonmar, mpickering, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3000
      
      GHC Trac Issues: #12223
      5d38fb69
  7. 20 Jan, 2017 1 commit
    • takano-akio's avatar
      Allow top-level string literals in Core (#8472) · d49b2bb2
      takano-akio authored
      This commits relaxes the invariants of the Core syntax so that a
      top-level variable can be bound to a primitive string literal of type
      Addr#.
      
      This commit:
      
      * Relaxes the invatiants of the Core, and allows top-level bindings whose
        type is Addr# as long as their RHS is either a primitive string literal or
        another variable.
      
      * Allows the simplifier and the full-laziness transformer to float out
        primitive string literals to the top leve.
      
      * Introduces the new StgGenTopBinding type to accomodate top-level Addr#
        bindings.
      
      * Introduces a new type of labels in the object code, with the suffix "_bytes",
        for exported top-level Addr# bindings.
      
      * Makes some built-in rules more robust. This was necessary to keep them
        functional after the above changes.
      
      This is a continuation of D2554.
      
      Rebasing notes:
      This had two slightly suspicious performance regressions:
      
      * T12425: bytes allocated regressed by roughly 5%
      * T4029: bytes allocated regressed by a bit over 1%
      * T13035: bytes allocated regressed by a bit over 5%
      
      These deserve additional investigation.
      
      Rebased by: bgamari.
      
      Test Plan: ./validate --slow
      
      Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari
      
      Reviewed By: trofi, simonpj, bgamari
      
      Subscribers: trofi, simonpj, gridaphobe, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2605
      
      GHC Trac Issues: #8472
      d49b2bb2
  8. 10 Jan, 2017 2 commits
    • David Feuer's avatar
      Inline partially-applied wrappers · 2be364ac
      David Feuer authored
      Suppose we have
      
      ```
      data Node a = Node2 !Int a a | Node3 !Int a a a
      instance Traversable Node where
        traverse f (Node2 s x y) = Node2 s <$> f x <*> f y
        ...
      
      ```
      
      Since `Node2` is partially applied, we wouldn't inline its
      wrapper.  The result was that we'd box up the `Int#` to put
      the box in the closure passed to `fmap`. We now allow the wrapper
      to inline when partially applied, so GHC stores the `Int#`
      directly in the closure.
      
      Reviewers: rwbarton, mpickering, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2891
      
      GHC Trac Issues: #12990
      2be364ac
    • takano-akio's avatar
      Mark *FB functions INLINE[0] (Fixes #13001) · 09bce7ac
      takano-akio authored
      When fusion rules successfully fire, we are left with calls to
      *FB functions. They are higher-order functions, and therefore they
      often benefit from inlining. This is particularly important when
      then final consumer is a strict fold (foldl', length, etc.), because
      not inlining these functions means allocating a function closure
      for each element in the list, which often is more costly than what
      fusion eliminates.
      
      Nofib shows a slight increase in the binary size:
      
      ------------------------------------------------------------------------
             Program           Size    Allocs   Runtime   Elapsed  TotalMem
      ------------------------------------------------------------------------
         gen_regexps          -0.3%      0.0%     0.000     0.000      0.0%
              puzzle          +0.8%      0.0%     0.089     0.090      0.0%
             reptile          +0.8%     -0.0%     0.008     0.008      0.0%
      ------------------------------------------------------------------------
                 Min          -0.3%     -0.0%     -7.3%     -7.1%      0.0%
                 Max          +0.8%     +0.0%     +7.8%     +7.7%     +1.8%
      Geometric Mean          +0.0%     -0.0%     +0.2%     +0.2%     +0.0%
      ------------------------------------------------------------------------
      
      Reviewers: simonpj, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2951
      
      GHC Trac Issues: #13001
      09bce7ac
  9. 20 Dec, 2016 1 commit
  10. 15 Dec, 2016 1 commit
    • Ben Gamari's avatar
      testsuite: Separate out Windows results for T5205 · d3981628
      Ben Gamari authored
      This test seems to have much different allocation behavior on Windows
      and Linux.  Previously we had widened the acceptance window to 7% to
      accomodate this, but even this isn't enough any more. Instead of further
      widening the window let's just give an expected number for each
      platform. Really, this is precisely the issue with our performance
      testing model which I've been complaining about in #12758.
      
      Fixes test for #5205 on 64-bit Windows.
      
      Test Plan: Validate on Windows
      
      Reviewers: austin
      
      Subscribers: thomie, Phyx
      
      Differential Revision: https://phabricator.haskell.org/D2848
      
      GHC Trac Issues: #5205
      d3981628
  11. 30 Nov, 2016 1 commit
    • Tamar Christina's avatar
      Update test output for Windows · dd9ba503
      Tamar Christina authored
      Following D2684 these two tests need to be updated:
      
       * T7037: timeout.exe now waits until all processes are finished.
                this makes T7037 reliable. So enabled.
      
       * T876: Unknown reason, allocations are much lower than before.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonmar, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2759
      
      GHC Trac Issues: #12725, #12004
      dd9ba503
  12. 12 Nov, 2016 1 commit
  13. 31 Aug, 2016 1 commit
    • Simon Marlow's avatar
      Bump the default allocation area size to 1MB · d790cb9d
      Simon Marlow authored
      This is long overdue.
      
      Perhaps 1MB is a little on the skinny size, but this is based on
      * A lot of commodity dual-core desktop processors have 3MB L3 cache
      * We're traditionally quite frugal with memory by default
      
      Test Plan: validate
      
      Reviewers: erikd, bgamari, hvr, austin, rwbarton, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2496
      d790cb9d
  14. 29 Jun, 2016 1 commit
    • thomie's avatar
      Testsuite: use ignore_stderr/stdout instead of ignore_output · 1084d375
      thomie authored
      The problem with ignore_output is that it hides errors for WAY=ghci.
      GHCi always returns with exit code 0 (unless it is broken itself).
      
      For example: ghci015 must have been failing with compile errors for
      years, but we didn't notice because all output was ignored.
      
      Therefore, replace all uses of ignore_output with either ignore_stderr
      or ignore_stdout. In some cases I opted for adding the expected output.
      
      Update submodule hpc and stm.
      
      Reviewed by: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2367
      1084d375
  15. 22 Jun, 2016 1 commit
  16. 18 Jun, 2016 1 commit
    • thomie's avatar
      Testsuite: run tests in <testdir>.run instead of /tmp · f72f23f9
      thomie authored
      As discussed in Phab:D1187, this approach makes it a bit easier to
      inspect the test directory while working on a new test.
      
      The only tests that needed changes are the ones that refer to files in
      ancestor directories. Those files are now copied directly into the test
      directory.
      
      validate still runs the tests in a temporary directory in /tmp, see
      `Note [Running tests in /tmp]` in testsuite/driver/runtests.py.
      
      Update submodule hpc.
      
      Reviewed by: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2333
      
      GHC Trac Issues: #11980
      f72f23f9
  17. 04 Jun, 2016 1 commit
  18. 06 Apr, 2016 1 commit
  19. 18 Dec, 2015 1 commit
  20. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      primops: Mark actions evaluated by `catch*` as lazy · 28638dfe
      Ben Gamari authored
      There is something very peculiar about the `catch` family of operations
      with respect to strictness analysis: they turn divergence into
      non-divergence. For this reason, it isn't safe to mark them as strict in
      the expression whose exceptions they are catching. The reason is this:
      
      Consider,
      
          let r = \st -> raiseIO# blah st
          in catch (\st -> ...(r st)..) handler st
      
      If we give the first argument of catch a strict signature, we'll get a
      demand 'C(S)' for 'r'; that is, 'r' is definitely called with one
      argument, which indeed it is. The trouble comes when we feed 'C(S)' into
      'r's RHS as the demand of the body as this will lead us to conclude that
      the whole 'let' will diverge; clearly this isn't right.
      
      This is essentially the problem in #10712, which arose when
      7c0fff41 marked the `catch*` primops as
      being strict in the thing to be evaluated. Here I've partially reverted
      this commit, again marking the first argument of these primops as lazy.
      
      Fixes #10712.
      
      Test Plan: Validate checking `exceptionsrun001`
      
      Reviewers: simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1616
      
      GHC Trac Issues: #10712, #11222
      28638dfe
  21. 12 Nov, 2015 1 commit
  22. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  23. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  24. 15 Aug, 2015 1 commit
  25. 11 Jul, 2015 1 commit
  26. 03 Jul, 2015 1 commit
  27. 20 Jun, 2015 1 commit
  28. 01 Jun, 2015 1 commit
  29. 18 May, 2015 1 commit
  30. 14 May, 2015 1 commit
  31. 13 May, 2015 1 commit
  32. 03 Apr, 2015 1 commit
  33. 03 Dec, 2014 1 commit
  34. 12 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement new integer-gmp2 from scratch (re #9281) · c774b28f
      Herbert Valerio Riedel authored
      This is done as a separate `integer-gmp2` backend library because it
      turned out to become a complete rewrite from scratch.
      
      Due to the different (over)allocation scheme and potentially different
      accounting (via the new `{shrink,resize}MutableByteArray#` primitives),
      some of the nofib benchmarks actually results in increased allocation
      numbers (but not necessarily an increase in runtime!).  I believe the
      allocation numbers could improve if `{resize,shrink}MutableByteArray#`
      could be optimised to reallocate in-place more efficiently.
      
      Here are the more apparent changes in the latest nofib comparision
      between `integer-gmp` and `integer-gmp2`:
      
        ------------------------------------------------------------------
                Program     Size    Allocs   Runtime   Elapsed  TotalMem
        ------------------------------------------------------------------
                    ...
             bernouilli    +1.6%    +15.3%     0.132     0.132      0.0%
                    ...
           cryptarithm1    -2.2%      0.0%     -9.7%     -9.7%      0.0%
                    ...
                  fasta    -0.7%     -0.0%    +10.9%    +10.9%      0.0%
                    ...
                  kahan    +0.6%    +38.9%     0.169     0.169      0.0%
                    ...
                   lcss    -0.7%     -0.0%     -6.4%     -6.4%      0.0%
                    ...
                 mandel    +1.6%    +33.6%     0.049     0.049      0.0%
                    ...
               pidigits    +0.8%     +8.5%     +3.9%     +3.9%      0.0%
                  power    +1.4%    -23.8%    -18.6%    -18.6%    -16.7%
                    ...
              primetest    +1.3%    +50.1%     0.085     0.085      0.0%
                    ...
                    rsa    +1.6%    +53.4%     0.026     0.026      0.0%
                    ...
                    scs    +1.2%     +6.6%     +6.5%     +6.6%    +14.3%
                    ...
                 symalg    +1.0%     +9.5%     0.010     0.010      0.0%
                    ...
              transform    -0.6%     -0.0%     -5.9%     -5.9%      0.0%
                    ...
        ------------------------------------------------------------------
                    Min    -2.3%    -23.8%    -18.6%    -18.6%    -16.7%
                    Max    +1.6%    +53.4%    +10.9%    +10.9%    +14.3%
         Geometric Mean    -0.3%     +1.9%     -0.8%     -0.8%     +0.0%
      
      (see P35 / https://phabricator.haskell.org/P35 for full report)
      
      By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which results
      in the package `integer-gmp-1.0.0.0` being registered in the package db.
      The previous `integer-gmp-0.5.1.0` can be restored by setting
      `INTEGER_LIBRARY=integer-gmp` (but will probably be removed altogether
      for GHC 7.12). In-tree GMP support has been stolen from the old
      `integer-gmp` (while unpatching the custom memory-allocators, as well as
      forcing `-fPIC`)
      
      A minor hack to `ghc-cabal` was necessary in order to support two different
      `integer-gmp` packages (in different folders) with the same package key.
      
      There will be a couple of follow-up commits re-implementing some features
      that were dropped to keep D82 minimal, as well as further
      clean-ups/improvements.
      
      More information can be found via #9281 and
      https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2
      
      Reviewed By: austin, rwbarton, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D82
      c774b28f
  35. 10 Sep, 2014 1 commit
    • Joachim Breitner's avatar
      Update performance numbers · 71c85300
      Joachim Breitner authored
      including some that are not failing yet, but did show a significant
      change, and some that Austing changed post-AMP, but where both
      harbormaster and ghcspeed reported something else. Numbers taken from
      the ghcspeed machine.
      71c85300
  36. 01 Sep, 2014 2 commits
  37. 24 Aug, 2014 1 commit