1. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  2. 27 Apr, 2018 1 commit
    • Simon Peyton Jones's avatar
      Better linting for types · 6da5b877
      Simon Peyton Jones authored
      Trac #15057 described deficiencies in the linting for types
      involving type synonyms.  This patch fixes an earlier attempt.
      
      The moving parts are desrcribed in
        Note [Linting type synonym applications]
      
      Not a big deal.
      6da5b877
  3. 20 Apr, 2018 2 commits
    • Tobias Dammers's avatar
      Caching coercion roles in NthCo and coercionKindsRole refactoring · 2fbe0b51
      Tobias Dammers authored
      While addressing nonlinear behavior related to coercion roles,
      particularly `NthCo`, we noticed that coercion roles are recalculated
      often even though they should be readily at hand already in most cases.
      This patch adds a `Role` to the `NthCo` constructor so that we can cache
      them rather than having to recalculate them on the fly.
      https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the
      approach.
      
      Performance improvement over GHC HEAD, when compiling Grammar.hs (see below):
      
      GHC 8.2.1:
      ```
      ghc Grammar.hs  176.27s user 0.23s system 99% cpu 2:56.81 total
      ```
      
      before patch (but with other optimizations applied):
      ```
      ghc Grammar.hs -fforce-recomp  175.77s user 0.19s system 100% cpu 2:55.78 total
      ```
      
      after:
      ```
      ../../ghc/inplace/bin/ghc-stage2 Grammar.hs  10.32s user 0.17s system 98% cpu 10.678 total
      ```
      
      Introduces the following regressions:
      
      - perf/compiler/parsing001 (possibly false positive)
      - perf/compiler/T9872
      - perf/compiler/haddock.base
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11735
      
      Differential Revision: https://phabricator.haskell.org/D4394
      2fbe0b51
    • Ryan Scott's avatar
      Lint types in newFamInst · 257c13d8
      Ryan Scott authored
      We weren't linting the types used in `newFamInst`, which
      might have been why #15012 went undiscovered for so long. Let's fix
      that.
      
      One has to be surprisingly careful with expanding type synonyms in
      `lintType`, since in the offending program (simplified):
      
      ```lang=haskell
      type FakeOut a = Int
      
      type family TF a
      type instance TF Int = FakeOut a
      ```
      
      If one expands type synonyms, then `FakeOut a` will expand to
      `Int`, which masks the issue (that `a` is unbound). I added an
      extra Lint flag to configure whether type synonyms should be
      expanded or not in Lint, and disabled this when calling `lintTypes`
      from `newFamInst`.
      
      As evidence that this works, I ran it on the offending program
      from #15012, and voilà:
      
      ```
      $ ghc3/inplace/bin/ghc-stage2 Bug.hs -dcore-lint
      [1 of 1] Compiling Foo              ( Bug.hs, Bug.o )
      ghc-stage2: panic! (the 'impossible' happened)
        (GHC version 8.5.20180417 for x86_64-unknown-linux):
              Core Lint error
        <no location info>: warning:
            In the type ‘... (Rec0 (FakeOut b_a1Qt))))’
            @ b_a1Qt is out of scope
      ```
      
      Test Plan: make test TEST=T15057
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15057
      
      Differential Revision: https://phabricator.haskell.org/D4611
      257c13d8
  4. 06 Mar, 2018 1 commit
    • niteria's avatar
      Allow top level ticked string literals · 5bc195a2
      niteria authored
      This reverts f5b275a2
      and changes the places that looked for `Lit (MachStr _))`
      to use `exprIsMbTickedLitString_maybe` to unwrap ticks as
      necessary.
      Also updated relevant comments.
      
      Test Plan:
      I added 3 new tests that previously reproduced.
      GHC HEAD now builds with -g
      
      Reviewers: simonpj, simonmar, bgamari, hvr, goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14779
      
      Differential Revision: https://phabricator.haskell.org/D4470
      5bc195a2
  5. 27 Feb, 2018 1 commit
  6. 07 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix utterly bogus TagToEnum rule in caseRules · 4aa98f4a
      Simon Peyton Jones authored
      In prelRules we had:
      
        tx_con_tte :: DynFlags -> AltCon -> AltCon
        tx_con_tte _      DEFAULT      = DEFAULT
        tx_con_tte dflags (DataAlt dc)
          | tag == 0  = DEFAULT   -- See Note [caseRules for tagToEnum]
          | otherwise = LitAlt (mkMachInt dflags (toInteger tag))
      
      The tag==0 case is totally wrong, and led directly to Trac #14768.
      
      See "Beware" in Note [caseRules for tagToEnum] (in the patch).
      
      Easily fixed, though!
      4aa98f4a
  7. 01 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Add -ddump-ds-preopt · efce943c
      Simon Peyton Jones authored
      This allows you to see the output immediately after desugaring
      but before any optimisation.
      
      I've wanted this for some time, but I was triggered into action
      by Trac #13032 comment:9.
      
      Interestingly, the change means that with -dcore-lint we will
      now Lint the output before the very simple optimiser;
      and this showed up Trac #14749.  But that's not the fault
      of -ddump-ds-preopt!
      efce943c
  8. 15 Jan, 2018 1 commit
  9. 21 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor coercion holes · a492af06
      Simon Peyton Jones authored
      In fixing Trac #14584 I found that it would be /much/ more
      convenient if a "hole" in a coercion (much like a unification
      variable in a type) acutally had a CoVar associated with it
      rather than just a Unique.  Then I can ask what the free variables
      of a coercion is, and get a set of CoVars including those
      as-yet-un-filled in holes.
      
      Once that is done, it makes no sense to stuff coercion holes
      inside UnivCo.  They were there before so we could know the
      kind and role of a "hole" coercion, but once there is a CoVar
      we can get that info from the CoVar.  So I removed HoleProv
      from UnivCoProvenance and added HoleCo to Coercion.
      
      In summary:
      
      * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
      
      * Similarly in IfaceCoercion
      
      * Make CoercionHole have a CoVar in it, not a Unique
      
      * Make tyCoVarsOfCo return the free coercion-hole variables
        as well as the ordinary free CoVars.  Similarly, remember
        to zonk the CoVar in a CoercionHole
      
      We could go further, and remove CoercionHole as a distinct type
      altogther, just collapsing it into HoleCo.  But I have not done
      that yet.
      a492af06
  10. 09 Nov, 2017 2 commits
  11. 30 Oct, 2017 1 commit
    • Michal Terepeta's avatar
      Allow packing constructor fields · cca2d6b7
      Michal Terepeta authored
      This is another step for fixing #13825 and is based on D38 by Simon
      Marlow.
      
      The change allows storing multiple constructor fields within the same
      word. This currently applies only to `Float`s, e.g.,
      ```
      data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Float
      ```
      on 64-bit arch, will now store both fields within the same constructor
      word. For `WordX/IntX` we'll need to introduce new primop types.
      
      Main changes:
      
      - We now use sizes in bytes when we compute the offsets for
        constructor fields in `StgCmmLayout` and introduce padding if
        necessary (word-sized fields are still word-aligned)
      
      - `ByteCodeGen` had to be updated to correctly construct the data
        types. This required some new bytecode instructions to allow pushing
        things that are not full words onto the stack (and updating
        `Interpreter.c`). Note that we only use the packed stuff when
        constructing data types (i.e., for `PACK`), in all other cases the
        behavior should not change.
      
      - `RtClosureInspect` was changed to handle the new layout when
        extracting subterms. This seems to be used by things like `:print`.
        I've also added a test for this.
      
      - I deviated slightly from Simon's approach and use `PrimRep` instead
        of `ArgRep` for computing the size of fields.  This seemed more
        natural and in the future we'll probably want to introduce new
        primitive types (e.g., `Int8#`) and `PrimRep` seems like a better
        place to do that (where we already have `Int64Rep` for example).
        `ArgRep` on the other hand seems to be more focused on calling
        functions.
      Signed-off-by: Michal Terepeta's avatarMichal Terepeta <michal.terepeta@gmail.com>
      
      Test Plan: ./validate
      
      Reviewers: bgamari, simonmar, austin, hvr, goldfire, erikd
      
      Reviewed By: bgamari
      
      Subscribers: maoe, rwbarton, thomie
      
      GHC Trac Issues: #13825
      
      Differential Revision: https://phabricator.haskell.org/D3809
      cca2d6b7
  12. 29 Oct, 2017 1 commit
    • Joachim Breitner's avatar
      Implement a dedicated exitfication pass #14152 · 0e953da1
      Joachim Breitner authored
      The idea is described in #14152, and can be summarized: Float the exit
      path out of a joinrec, so that the simplifier can do more with it.
      See the test case for a nice example.
      
      The floating goes against what the simplifier usually does, hence we
      need to be careful not inline them back.
      
      The position of exitification in the pipeline was chosen after a small
      amount of experimentation, but may need to be improved. For example,
      exitification can allow rewrite rules to fire, but for that it would
      have to happen before the `simpl_phases`.
      
      Perf.haskell.org reports these nice performance wins:
      
          Nofib allocations
          fannkuch-redux    78446640  - 99.92%      64560
          k-nucleotide     109466384  - 91.32%    9502040
          simple            72424696  -  5.96%   68109560
      
          Nofib instruction counts
          fannkuch-redux  1744331636  -  3.86% 1676999519
          k-nucleotide    2318221965  -  6.30% 2172067260
          scs             1978470869  -  3.35% 1912263779
          simple           669858104  -  3.38%  647206739
          spectral-norm    186423292  -  5.37%  176411536
      
      Differential Revision: https://phabricator.haskell.org/D3903
      0e953da1
  13. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  14. 09 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Canonicalise MonoidFail instances in GHC · 346e562a
      Herbert Valerio Riedel authored
      IOW, code compiles -Wnoncanonical-monoidfail-instances clean now
      
      This is easy now since we require GHC 8.0/base-4.9 or later
      for bootstrapping.
      
      Note that we can easily enable `MonadFail` via
      
        default-extensions: MonadFailDesugaring
      
      in compiler/ghc.cabal.in
      
      which currently would point out that NatM doesn't have
      a proper `fail` method, even though failable patterns
      are made use of:
      
        compiler/nativeGen/SPARC/CodeGen.hs:425:25: error:
          * No instance for (Control.Monad.Fail.MonadFail NatM)
              arising from a do statement
              with the failable pattern ‘(dyn_c, [dyn_r])’
      346e562a
  15. 31 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Add debugPprType · 805b29bb
      Simon Peyton Jones authored
      We pretty-print a type by converting it to an IfaceType and
      pretty-printing that.  But
       (a) that's a bit indirect, and
       (b) delibrately loses information about (e.g.) the kind
            on the /occurrences/ of a type variable
      
      So this patch implements debugPprType, which pretty prints
      the type directly, with no fancy formatting.  It's just used
      for debugging.
      
      I took the opportunity to refactor the debug-pretty-printing
      machinery a little.  In particular, define these functions
      and use them:
      
        ifPprDeubug :: SDoc -> SDOc -> SDoc
          -- Says what to do with and without -dppr-debug
        whenPprDebug :: SDoc -> SDoc
          -- Says what to do with  -dppr-debug; without is empty
        getPprDebug :: (Bool -> SDoc) -> SDoc
      
      getPprDebug used to be called sdocPprDebugWith
      whenPprDebug used to be called ifPprDebug
      
      So a lot of files get touched in a very mechanical way
      805b29bb
  16. 29 Aug, 2017 1 commit
  17. 18 Aug, 2017 1 commit
  18. 12 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Use NonEmpty lists to represent lists of duplicate elements · 7d699782
      Ryan Scott authored
      Summary:
      Three functions in `ListSetOps` which compute duplicate elements
      represent lists of duplicates of `[a]`. This is a really bad way to go about
      things, because these lists are guaranteed to always have at least one element
      (the "representative" of the duplicates), and several places in the GHC API
      call `head` (a partial function) on these lists of duplicates to retrieve the
      representative.
      
      This changes the representation of duplicates to `NonEmpty` lists instead,
      which allow for many partial uses of `head` to be made total.
      
      Fixes #13823.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13823
      
      Differential Revision: https://phabricator.haskell.org/D3823
      7d699782
  19. 01 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Drop GHC 7.10 compatibility · c13720c8
      Ryan Scott authored
      GHC 8.2.1 is out, so now GHC's support window only extends back to GHC
      8.0. This means we can delete gobs of code that was only used for GHC
      7.10 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, austin, goldfire, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3781
      c13720c8
  20. 02 Jun, 2017 1 commit
    • Ryan Scott's avatar
      Use lengthIs and friends in more places · a786b136
      Ryan Scott authored
      While investigating #12545, I discovered several places in the code
      that performed length-checks like so:
      
      ```
      length ts == 4
      ```
      
      This is not ideal, since the length of `ts` could be much longer than 4,
      and we'd be doing way more work than necessary! There are already a slew
      of helper functions in `Util` such as `lengthIs` that are designed to do
      this efficiently, so I found every place where they ought to be used and
      did just that. I also defined a couple more utility functions for list
      length that were common patterns (e.g., `ltLength`).
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, goldfire, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: goldfire, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3622
      a786b136
  21. 03 May, 2017 1 commit
  22. 06 Apr, 2017 1 commit
  23. 31 Mar, 2017 1 commit
  24. 29 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Allow unbound Refl binders in a RULE · 8674883c
      Simon Peyton Jones authored
      Trac #13410 was failing because we had a RULE with a binder
         (c :: t~t)
      and the /occurrences/ of c on the LHS were being optimised to Refl,
      leaving a binder that would not be filled in by matching the LHS
      of the rule.
      
      I flirted with trying to ensure that occurrences (c :: t~t) are
      not optimised to Relf, but that turned out to be fragile; it was
      being done, for good reasons, in multiple places, including
        - TyCoRep.substCoVarBndr
        - Simplify.simplCast
        - Corecion.mkCoVarCo
      
      So I fixed it in one place by making Rules.matchN deal happily
      with an unbound binder (c :: t~t).  Quite easy.  See "Coercion
      variables" in Note [Unbound RULE binders] in Rules.
      
      In addition, I needed to make CoreLint be happy with an bound
      RULE binder that is a Relf coercion variable
      
      In debugging this, I was perplexed that occurrences of a variable
      (c :: t~t) mysteriously turned into Refl.  I found out how it
      was happening, and decided to move it:
      
      * In TyCoRep.substCoVarBndr, do not substitute Refl for a
        binder (c :: t~t).
      
      * In mkCoVarCo do not optimise (c :: t~t) to Refl.
      
      Instead, we do this optimisation in optCoercion (specifically
      opt_co4) where, surprisingly, the optimisation was /not/
      being done.  This has no effect on what programs compile;
      it just moves a relatively-expensive optimisation to optCoercion,
      where it seems more properly to belong.  It's actually not clear
      to me which is really "better", but this way round is less
      surprising.
      
      One small simplifying refactoring
      
      * Eliminate TyCoRep.substCoVarBndrCallback, which was only
        called locally.
      8674883c
  25. 28 Mar, 2017 1 commit
  26. 27 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13458 · cea71418
      Richard Eisenberg authored
      Core Lint shouldn't check representations of types that don't
      have representations.
      
      test case: typecheck/should_compile/T13458
      cea71418
  27. 17 Mar, 2017 1 commit
  28. 15 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Introduce putLogMsg · 086b514b
      Ben Gamari authored
      This factors out the repetition of (log_action dflags dflags) and will
      hopefully allow us to someday better abstract log output.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3334
      086b514b
  29. 11 Mar, 2017 1 commit
  30. 08 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Join points can be levity-polymorphic · 8e053700
      Simon Peyton Jones authored
      It's ok to have a levity-polymorphic join point, thus
         let j :: r :: TYPE l = blah
         in ...
      
      Usually we don't allow levity-polymorphic binders, but join points
      are different because they are not first class.  I updated the
      invariants in CoreSyn.
      
      This commit fixes Trac #13394.
      8e053700
  31. 21 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve Core Lint, mainly for join points · e790126c
      Simon Peyton Jones authored
      * lintSingleBinding: check that join points have
                           a valid join-point type
        (Trac #13281)
      
      * lintIdBinder: check that a JoinId is bound by
                      a non-top-level let
        i.e.  not a top level binder
              not lambda/case binder
      
      * Check for empty Rec [] bindings
      
      * Rename lintIdBndrs to lintLetBndrs
      e790126c
  32. 18 Feb, 2017 2 commits
    • 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
    • Ben Gamari's avatar
      Generalize kind of the (->) tycon · b207b536
      Ben Gamari authored
      This is generalizes the kind of `(->)`, as discussed in #11714.
      
      This involves a few things,
      
       * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep`
      binders,
        ```lang=haskell
      (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep)
                     (a :: TYPE r1) (b :: TYPE r2).
              a -> b -> *
        ```
      
       * Unsaturated applications of `(->)` are expressed as explicit
      `TyConApp`s
      
       * Saturated applications of `(->)` are expressed as `FunTy` as they are
      currently
      
       * Saturated applications of `(->)` are expressed by a new `FunCo`
      constructor in coercions
      
       * `splitTyConApp` needs to ensure that `FunTy`s are split to a
      `TyConApp`
         of `(->)` with the appropriate `RuntimeRep` arguments
      
       * Teach CoreLint to check that all saturated applications of `(->)` are
      represented with `FunTy`
      
      At the moment I assume that `Constraint ~ *`, which is an annoying
      source of complexity. This will
      be simplified once D3023 is resolved.
      
      Also, this introduces two known regressions,
      
      `tcfail181`, `T10403`
      =====================
      Only shows the instance,
      
          instance Monad ((->) r) -- Defined in ‘GHC.Base’
      
      in its error message when -fprint-potential-instances is used. This is
      because its instance head now mentions 'LiftedRep which is not in scope.
      I'm not entirely sure of the right way to fix this so I'm just accepting
      the new output for now.
      
      T5963 (Typeable)
      ================
      
      T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its
      fingerprint without the RuntimeRep variables that (->) expects. This
      will be fixed with the merge of D2010.
      
      Haddock performance
      ===================
      
      The `haddock.base` and `haddock.Cabal` tests regress in allocations by
      about 20%. This certainly hurts, but it's also not entirely unexpected:
      the size of every function type grows with this patch and Haddock has a
      lot of functions in its heap.
      b207b536
  33. 16 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve checking of joins in Core Lint · 6bab649b
      Simon Peyton Jones authored
      This patch addresses the rather expensive treatment of join points,
      identified in Trac #13220 comment:17
      
      Before we were tracking the "bad joins".  Now we track the good ones.
      That is easier to think about, and much more efficient; see CoreLint
      Note [Join points].
      
      On the way I did some other modest refactoring, among other things
      removing a duplicated call of lintIdBndr for let-bindings.
      
      On teh
      6bab649b
  34. 03 Feb, 2017 1 commit
    • Sylvain Henry's avatar
      Ditch static flags · bbd3c399
      Sylvain Henry authored
      This patch converts the 4 lasting static flags (read from the command
      line and unsafely stored in immutable global variables) into dynamic
      flags. Most use cases have been converted into reading them from a DynFlags.
      
      In cases for which we don't have easy access to a DynFlags, we read from
      'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'.
      It's not perfect (not thread-safe) but it is still better as we can
      set/unset these 4 flags before each run when using GHC API.
      
      Updates haddock submodule.
      
      Rebased and finished by: bgamari
      
      Test Plan: validate
      
      Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2839
      
      GHC Trac Issues: #8440
      bbd3c399
  35. 01 Feb, 2017 1 commit
  36. 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
  37. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2