1. 03 Apr, 2018 1 commit
  2. 02 Apr, 2018 1 commit
    • Simon Peyton Jones's avatar
      Allow unpacking of single-data-con GADTs · 9187d5fb
      Simon Peyton Jones authored
      Trac #14978 pointed out that single-constructor GADTs should be
      unpackable without trouble.
      
      Acutally I realise that even existentials should be unpackable
      too, but that's a bit more work, so it's not part of this patch.
      
      See Note [Unpacking GADTs and existentials] in MkId.
      9187d5fb
  3. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
      
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      TcErrors.
      
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
      
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
      
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
         -fprint-explicit-runtime-reps
      
      Fixes #14066 #14749
      
      Test cases: dependent/should_compile/{T14066a,T14749},
                  dependent/should_fail/T14066{,c,d,e,f,g,h}
      faec8d35
  4. 25 Mar, 2018 1 commit
  5. 22 Mar, 2018 1 commit
    • Simon Peyton Jones's avatar
      Improve shortOutIndirections slightly · 034c32f6
      Simon Peyton Jones authored
      I found (when investigating Trac #14955) a binding looking like
      
         Rec { exported_id = ....big...lcl_id...
             ; lcl_id = exported_id }
      
      but bizarrely 'lcl_id' was chosen as the loop breaker, and never
      inlined.  It turned out to be an unintended consequence of the
      shortOutIndirections code in SimplCore.  Easily fixed.
      034c32f6
  6. 19 Mar, 2018 1 commit
  7. 13 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Drop GHC 8.0 compatibility · 152055a1
      Ryan Scott authored
      GHC 8.4.1 is out, so now GHC's support window only extends
      back to GHC 8.2. This means we can delete gobs of code that were
      only used for GHC 8.0 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: bgamari, erikd, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: alexbiehl, dfeuer, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4492
      152055a1
  8. 02 Feb, 2018 1 commit
  9. 01 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Experiment with eliminating the younger tyvar · 618a805b
      Simon Peyton Jones authored
      This patch is comments only, plus a minor refactor that
      does not change behaviour.
      
      It just records an idea I had for reducing kick-out in the type
      constraint-solver.
      
      See Note [Eliminate younger unification variables] in TcUnify.
      
      Sadly, it didn't improve perf, so I've put it aside, leaving
      some breadcrumbs for future generations of GHC hackers.
      618a805b
  10. 17 Jan, 2018 1 commit
  11. 10 Jan, 2018 1 commit
    • niteria's avatar
      Lift constructor tag allocation out of a loop · dbdf77d9
      niteria authored
      Before this change, for each constructor that we want
      to allocate a tag for we would traverse a list of all
      the constructors in a datatype to determine which tag
      a constructor should get.
      
      This is obviously quadratic and for datatypes with 10k
      constructors it actually makes a big difference.
      
      This change implements the plan outlined by @simonpj in
      https://mail.haskell.org/pipermail/ghc-devs/2017-October/014974.html
      which is basically about using a map and constructing it outside the
      loop.
      
      One place where things got a bit awkward was TysWiredIn.hs,
      it would have been possible to just assign the tags by hand, but
      that seemed error-prone to me, so I decided to go through a map
      there as well.
      
      Test Plan:
      ./validate
      On a file with 10k constructors
      Before:
         8,130,522,344 bytes allocated in the heap
        Total   time    3.682s  (  3.920s elapsed)
      After:
         4,133,478,744 bytes allocated in the heap
        Total   time    2.509s  (  2.750s elapsed)
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: goldfire, rwbarton, thomie, simonmar, carter, simonpj
      
      GHC Trac Issues: #14657
      
      Differential Revision: https://phabricator.haskell.org/D4289
      dbdf77d9
  12. 04 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Drop dead Given bindings in setImplicationStatus · 954cbc7c
      Simon Peyton Jones authored
      Trac #13032 pointed out that we sometimes generate unused
      bindings for Givens, and (worse still) we can't always discard
      them later (we don't drop a case binding unless we can prove
      that the scrutinee is non-bottom.
      
      It looks as if this may be a major reason for the performace
      problems in #14338 (see comment:29).
      
      This patch fixes the problem at source, by pruning away all the
      dead Givens.  See Note [Delete dead Given evidence bindings]
      
      Remarkably, compiler allocation falls by 23% in
      perf/compiler/T12227!
      
      I have not confirmed whether this change actualy helps with
      954cbc7c
  13. 03 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Get evaluated-ness right in the back end · bd438b2d
      Simon Peyton Jones authored
      See Trac #14626, comment:4.  We want to maintain evaluted-ness
      info on Ids into the code generateor for two reasons
      (see Note [Preserve evaluated-ness in CorePrep] in CorePrep)
      
      - DataToTag magic
      - Potentially using it in the codegen (this is Gabor's
        current work)
      
      But it was all being done very inconsistently, and actually
      outright wrong -- the DataToTag magic hasn't been working for
      years.
      
      This patch tidies it all up, with Notes to match.
      bd438b2d
  14. 19 Dec, 2017 2 commits
  15. 18 Dec, 2017 2 commits
  16. 13 Dec, 2017 2 commits
    • Simon Peyton Jones's avatar
      Tidy up of wired-in names · 321b420f
      Simon Peyton Jones authored
      Two things here:
      
      * While debugging Trac #14561 I found it hard to understand
        ghcPrimIds and magicIds in MkId.  This patch adds more
        structure and comments.
      
      * I also discovered that ($) no longer needs to be a wiredInId
        because we now have levity polymorphism.  So I took dollarId
        out of MkId; and gave it a levity-polymorphic type in GHC.Base
      321b420f
    • Simon Peyton Jones's avatar
      Detect levity-polymorphic uses of unsafeCoerce# · e40db7b1
      Simon Peyton Jones authored
      This bug was shown up by Trac #14561. The deguarer carefully
      detects unsaturated and levity-polymorphic uses of primops,
      but not of things like unsafeCoerce#.
      
      The fix is simple: see Note [Levity-polymorphic Ids] in Id.
      e40db7b1
  17. 02 Nov, 2017 1 commit
  18. 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
  19. 07 Oct, 2017 1 commit
    • Ryan Scott's avatar
      Incorporate changes from #11721 into Template Haskell · 341d3a78
      Ryan Scott authored
      Summary:
      #11721 changed the order of type variables in GADT
      constructor type signatures, but these changes weren't reflected in
      Template Haskell reification of GADTs. Let's do that.
      
      Along the way, I:
      
      * noticed that the `T13885` test was claiming to test TH reification
        of GADTs, but the reified data type wasn't actually a GADT! Since
        this patch touches that part of the codebase, I decided to fix
        this.
      * incorporated some feedback from @simonpj in
        https://phabricator.haskell.org/D3687#113566. (These changes alone
        don't account for any different in behavior.)
      
      Test Plan: make test TEST=T11721_TH
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: goldfire, bgamari, simonpj
      
      Subscribers: rwbarton, thomie, simonpj
      
      GHC Trac Issues: #11721
      
      Differential Revision: https://phabricator.haskell.org/D4070
      341d3a78
  20. 03 Oct, 2017 2 commits
    • Ryan Scott's avatar
      Track the order of user-written tyvars in DataCon · ef26182e
      Ryan Scott authored
      After typechecking a data constructor's type signature, its type
      variables are partitioned into two distinct groups: the universally
      quantified type variables and the existentially quantified type
      variables. Then, when prompted for the type of the data constructor,
      GHC gives this:
      
      ```lang=haskell
      MkT :: forall <univs> <exis>. (...)
      ```
      
      For H98-style datatypes, this is a fine thing to do. But for GADTs,
      this can sometimes produce undesired results with respect to
      `TypeApplications`. For instance, consider this datatype:
      
      ```lang=haskell
      data T a where
        MkT :: forall b a. b -> T a
      ```
      
      Here, the user clearly intended to have `b` be available for visible
      type application before `a`. That is, the user would expect
      `MkT @Int @Char` to be of type `Int -> T Char`, //not//
      `Char -> T Int`. But alas, up until now that was not how GHC
      operated—regardless of the order in which the user actually wrote
      the tyvars, GHC would give `MkT` the type:
      
      ```lang=haskell
      MkT :: forall a b. b -> T a
      ```
      
      Since `a` is universal and `b` is existential. This makes predicting
      what order to use for `TypeApplications` quite annoying, as
      demonstrated in #11721 and #13848.
      
      This patch cures the problem by tracking more carefully the order in
      which a user writes type variables in data constructor type
      signatures, either explicitly (with a `forall`) or implicitly
      (without a `forall`, in which case the order is inferred). This is
      accomplished by adding a new field `dcUserTyVars` to `DataCon`, which
      is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to
      the order in which the user wrote them. For more details, refer to
      `Note [DataCon user type variables]` in `DataCon.hs`.
      
      An interesting consequence of this design is that more data
      constructors require wrappers. This is because the workers always
      expect the first arguments to be the universal tyvars followed by the
      existential tyvars, so when the user writes the tyvars in a different
      order, a wrapper type is needed to swizzle the tyvars around to match
      the order that the worker expects. For more details, refer to
      `Note [Data con wrappers and GADT syntax]` in `MkId.hs`.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: ezyang, goldfire, rwbarton, thomie
      
      GHC Trac Issues: #11721, #13848
      
      Differential Revision: https://phabricator.haskell.org/D3687
      ef26182e
    • Simon Peyton Jones's avatar
      Fix nasty bug in w/w for absence analysis · dbbee1ba
      Simon Peyton Jones authored
      This dark corner was exposed by Trac #14285.  It involves the
      interaction between absence analysis and INLINABLE pragmas.
      
      There is a full explanation in Note [aBSENT_ERROR_ID] in MkCore,
      which you can read there.  The changes in this patch are
      
      * Make exprIsHNF return True for absentError, treating
        absentError like an honorary data constructor.
      
      * Make absentError /not/ be diverging, unlike other error Ids.
      
      This is all a bit horrible.
      
      * While doing this I found that exprOkForSpeculation didn't
        have a case for value lambdas so I added one.  It's not
        really called on lifted types much, but it seems like the
        right thing
      dbbee1ba
  21. 29 Sep, 2017 1 commit
  22. 28 Sep, 2017 1 commit
    • Simon Marlow's avatar
      mkDataConRep: fix bug in strictness signature (#14290) · 5935acdb
      Simon Marlow authored
      The strictness signature for a data con wrapper wasn't including any
      dictionary arguments, which meant that bangs on the fields of a
      constructor with an existential context would be moved to the wrong
      fields.  See T14290 for an example.
      
      Test Plan:
      * New test T14290
      * validate
      
      Reviewers: simonpj, niteria, austin, bgamari, erikd
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14290
      
      Differential Revision: https://phabricator.haskell.org/D4040
      5935acdb
  23. 26 Sep, 2017 1 commit
  24. 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
  25. 13 Sep, 2017 1 commit
    • Ben Gamari's avatar
      Model divergence of retry# as ThrowsExn, not Diverges · 10a1a478
      Ben Gamari authored
      The demand signature of the retry# primop previously had a Diverges
      result.  However, this caused the demand analyser to conclude that a
      program of the shape,
      
          catchRetry# (... >> retry#)
      
      would diverge. Of course, this is plainly wrong; catchRetry#'s sole
      reason to exist is to "catch" the "exception" thrown by retry#. While
      catchRetry#'s demand signature correctly had the ExnStr flag set on its
      first argument, indicating that it should catch divergence, the logic
      associated with this flag doesn't apply to Diverges results. This
      resulted in #14171.
      
      The solution here is to treat the divergence of retry# as an exception.
      Namely, give it a result type of ThrowsExn rather than Diverges.
      
      Updates stm submodule for tests.
      
      Test Plan: Validate with T14171
      
      Reviewers: simonpj, austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14171, #8091
      
      Differential Revision: https://phabricator.haskell.org/D3919
      10a1a478
  26. 12 Sep, 2017 1 commit
  27. 07 Sep, 2017 1 commit
  28. 05 Sep, 2017 1 commit
  29. 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
  30. 29 Aug, 2017 1 commit
  31. 18 Aug, 2017 1 commit
  32. 02 Aug, 2017 1 commit
  33. 01 Aug, 2017 1 commit
  34. 31 Jul, 2017 1 commit
  35. 30 Jul, 2017 1 commit
  36. 28 Jul, 2017 1 commit