1. 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
  2. 12 Sep, 2017 2 commits
  3. 05 Aug, 2017 1 commit
  4. 04 Apr, 2017 1 commit
    • David Feuer's avatar
      Revert "Make raiseIO# produce topRes" · e83af07e
      David Feuer authored
      This reverts commit da4687f6.
      
      It's not entirely trivial to clean up the dead code this patch
      introduced. In particular, when we see
      
      ```
      case raiseIO# m s of
        s' -> e
      ```
      
      we want to know that `e` is dead. For scrutinees that are properly
      bottom (which we don't want to consider `raiseIO# m s` to be, this
      is handled by rewriting `bot` to `case bot of {}`. But if we do
      that for `raiseIO#`, we end up with
      
      ```
      case raiseIO# m s of {}
      ```
      
      which looks a lot like bottom and could confuse demand analysis.
      I think we need to wait with this change until we have a more
      complete story.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3413
      e83af07e
  5. 09 Mar, 2017 1 commit
  6. 06 Mar, 2017 1 commit
  7. 26 Feb, 2017 1 commit
    • rwbarton's avatar
      tests: remove extra_files.py (#12223) · 3415bcaa
      rwbarton authored
      The script I used is included as testsuite/driver/kill_extra_files.py,
      though at this point it is for mostly historical interest.
      
      Some of the tests in libraries/hpc relied on extra_files.py, so this
      commit includes an update to that submodule.
      
      One test in libraries/process also relies on extra_files.py, but we
      cannot update that submodule so easily, so for now we special-case it
      in the test driver.
      3415bcaa
  8. 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
  9. 23 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Record evaluated-ness on workers and wrappers · 596dece7
      Simon Peyton Jones authored
      Summary:
      This patch is a refinement of the original commit (which
      was reverted):
      
        commit 6b976eb8
        Date:   Fri Jan 13 08:56:53 2017 +0000
            Record evaluated-ness on workers and wrappers
      
      In Trac #13027, comment:20, I noticed that wrappers created after
      demand analysis weren't recording the evaluated-ness of strict
      constructor arguments.  In the ticket that led to a (debatable)
      Lint error but in general the more we know about evaluated-ness
      the better we can optimise.
      
      This commit adds that info
        * both in the worker (on args)
        * and in the wrapper (on CPR result patterns).
      See Note [Record evaluated-ness in worker/wrapper] in WwLib
      
      On the way I defined Id.setCaseBndrEvald, and used it to shorten
      the code in a few other places
      
      Then I added test T13077a to test the CPR aspect of this patch,
      but I found that Lint failed!
      
      Reason: simpleOptExpr was discarding evaluated-ness info on
      lambda binders because zapFragileIdInfo was discarding an
      Unfolding of (OtherCon _).  But actually that's a robust
      unfolding; there is no need to discard it. To fix this:
      
      * zapFragileIdInfo only zaps fragile unfoldings
      
      * Replace isClosedUnfolding with isFragileUnfolding (the latter
        is just the negation of the former, but the nomenclature is
        more consistent).  Better documentation too
             Note [Fragile unfoldings]
      
      * And Simplify.simplLamBndr can now look at isFragileUnfolding
        to decide whether to use the longer route of simplUnfolding.
      
      For some reason perf/compiler/T9233 improves in compile-time
      allocation by 10%.  Hooray
      
      Nofib: essentially no change:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
            cacheprof          +0.0%     -0.3%     +0.9%     +0.4%     +0.0%
      --------------------------------------------------------------------------------
                  Min          +0.0%     -0.3%     -2.4%     -2.4%     +0.0%
                  Max          +0.0%     +0.0%     +9.8%    +11.4%     +2.4%
       Geometric Mean          +0.0%     -0.0%     +1.1%     +1.0%     +0.0%
      596dece7
  10. 22 Jan, 2017 1 commit
  11. 09 Jan, 2017 1 commit
  12. 23 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix a bug in ABot handling in CoreArity · f06b71ae
      Simon Peyton Jones authored
      See Note [ABot branches: use max] in CoreArity.
      
      I stumbled on this when investigating something else, and
      opened Trac #13031 to track it.
      
      It's very hard to tickle the bug, which is why it has lurked so long,
      but the test
         stranal/should_compile/T13031
      does so
      
      Oddly, the testsuite framework doesn't actually run the test; I have
      no idea why.
      f06b71ae
  13. 25 Aug, 2016 2 commits
    • Joachim Breitner's avatar
      DmdAnal: Testcase about splitFVs and dmdFix abortion · d6fd2e37
      Joachim Breitner authored
      Any variable with useful information (strict or used-once) will not be
      included in lazy_fv (according to splitFVs). If we now also remove them
      from the strictness signatures, their uses are not recorded anywhere –
      and then probably considered absent.
      d6fd2e37
    • Joachim Breitner's avatar
      DmdAnal: Add a final, safe iteration · 8d92b88d
      Joachim Breitner authored
      this fixes #12368.
      
      It also refactors dmdFix a bit, removes some redundancies (such as
      passing around an strictness signature right next to an id, when that id
      is guaranteed to have been annotated with that strictness signature).
      
      Note that when fixed-point iteration does not terminate, we
      conservatively delete their strictness signatures (set them to nopSig).
      But this loses the information on how its strict free variables are
      used!
      
      Lazily used variables already escape via lazy_fvs. We ensure that in the
      case of an aborted fixed-point iteration, also the strict variables are
      put there (with a conservative demand of topDmd).
      
      Differential Revision: https://phabricator.haskell.org/D2392
      8d92b88d
  14. 24 Jul, 2016 1 commit
  15. 12 Jul, 2016 1 commit
    • Joachim Breitner's avatar
      Demand analyser: Implement LetUp rule (#12370) · 45d8f4eb
      Joachim Breitner authored
      This makes the implementation match the description in the paper more
      closely: There, a let binding that is not a function has first its body
      analised, and then the binding’s RHS. This way, the demand on the bound
      variable by the body can be fed into the RHS, yielding more precise
      results.
      
      Performance measurements do unfortunately not show significant
      improvements or regessions.
      
      Differential Revision: https://phabricator.haskell.org/D2395
      45d8f4eb
  16. 07 Jul, 2016 1 commit
  17. 20 Jun, 2016 1 commit
  18. 24 May, 2016 1 commit
    • seraphime's avatar
      Fix: #12084 deprecate old profiling flags · 1956cbf1
      seraphime authored
      Change help message so it doesn't specify -auto-all.
      Make old profiling flags deprecated as they are no longer
      documented.
      Update Makefile and documentation accordingly.
      Update release notes for ghc 8.2
      
      Test Plan:
      ./verify; `ghc --help` shouldn't specify the -auto-all
      flag. Furthermore `ghc -fprof -auto-all` should emit a warning
      
      Reviewed By: thomie, austin
      
      Differential Revision: https://phabricator.haskell.org/D2257
      
      GHC Trac Issues: #12084
      
      Update submodule nofib
      1956cbf1
  19. 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
  20. 06 Apr, 2016 1 commit
    • Joachim Breitner's avatar
      Demand Analyzer: Do not set OneShot information (second try) · 0f58d348
      Joachim Breitner authored
      as suggested in ticket:11770#comment:1. This code was buggy
      (#11770), and the occurrence analyzer does the same job anyways.
      
      This also elaborates the notes in the occurrence analyzer accordingly.
      
      Previously, the worker/wrapper code would go through lengths to transfer
      the oneShot annotations from the original function to both the worker
      and the wrapper. We now simply transfer the demand on the worker, and
      let the subsequent occurrence analyzer push this onto the lambda
      binders.
      
      This also requires the occurrence analyzer to do this more reliably.
      Previously, it would not hand out OneShot annotatoins to things that
      would not `certainly_inline` (and it might not have mattered, as the
      Demand Analysis might have handed out the annotations). Now we hand out
      one-shot annotations unconditionally.
      
      Differential Revision: https://phabricator.haskell.org/D2085
      0f58d348
  21. 31 Mar, 2016 2 commits
  22. 30 Mar, 2016 2 commits
    • Ben Gamari's avatar
      Kill the magic of Any · 24d76153
      Ben Gamari authored
      This turns `Any` into a standard wired-in type family defined in
      `GHC.Types`, instead its current incarnation as a magical creature
      provided by the `GHC.Prim`.  Also kill `AnyK`.
      
      See #10886.
      
      Test Plan: Validate
      
      Reviewers: simonpj, goldfire, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2049
      
      GHC Trac Issues: #10886
      24d76153
    • Joachim Breitner's avatar
      Add testcase for #11770 · cb9a1e68
      Joachim Breitner authored
      and use normalise_errmsg_fun to check the core output in all.T, instead
      relying on code in the Makefile.
      cb9a1e68
  23. 29 Mar, 2016 1 commit
  24. 11 Mar, 2016 1 commit
  25. 08 Mar, 2016 1 commit
  26. 25 Feb, 2016 2 commits
    • thomie's avatar
      Testsuite: delete empty files [skip ci] · 9b49c65f
      thomie authored
      9b49c65f
    • manav's avatar
      Make warning names more consistent · 66584914
      manav authored
      - Replace "Sigs" with "Signatures" in WarningFlag data constructors.
      - Replace "PatSyn" with "PatternSynonym" in WarningFlag data
        constructors.
      - Deprecate "missing-local-sigs" in favor of "missing-local-signatures".
      - Deprecate "missing-exported-sigs" in favor of
        "missing-exported-signatures".
      - Deprecate "missing-pat-syn-signatures" in favor of
        "missing-pattern-synonym-signatures".
      - Replace "ddump-strsigs" with "ddump-str-signatures"
      
      These complete the tasks that were explicitly mentioned in #11583
      
      Test Plan:
      Executed `ghc --show-options` and verified that the flags were changed
      as expected.
      
      Reviewers: svenpanne, austin, bgamari
      
      Reviewed By: austin, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1939
      
      GHC Trac Issues: #11583
      66584914
  27. 23 Feb, 2016 1 commit
  28. 18 Feb, 2016 1 commit
    • Ben Gamari's avatar
      Unwire Typeable representation types · 206a8bf4
      Ben Gamari authored
      In order to make this work I needed to shuffle around typechecking a bit
      such that `TyCon` and friends are available during compilation of
      GHC.Types.  I also did a bit of refactoring of `TcTypeable`.
      
      Test Plan: Validate
      
      Reviewers: simonpj, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1906
      
      GHC Trac Issues: #11120
      206a8bf4
  29. 11 Feb, 2016 1 commit
  30. 07 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Make demand analysis understand catch · 9915b656
      Simon Peyton Jones authored
      As Trac #11222, and #10712 note, the strictness analyser
      needs to be rather careful about exceptions.  Previously
      it treated them as identical to divergence, but that
      won't quite do.
      
      See Note [Exceptions and strictness] in Demand, which
      explains the deal.
      
      Getting more strictness in 'catch' and friends is a
      very good thing.  Here is the nofib summary, keeping
      only the big ones.
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                fasta          -0.1%     -6.9%     -3.0%     -3.0%     +0.0%
                  hpg          -0.1%     -2.0%     -6.2%     -6.2%     +0.0%
             maillist          -0.1%     -0.3%      0.08      0.09     +1.2%
      reverse-complem          -0.1%    -10.9%     -6.0%     -5.9%     +0.0%
               sphere          -0.1%     -4.3%      0.08      0.08     +0.0%
                 x2n1          -0.1%     -0.0%      0.00      0.00     +0.0%
      --------------------------------------------------------------------------------
                  Min          -0.2%    -10.9%    -17.4%    -17.3%     +0.0%
                  Max          -0.0%     +0.0%     +4.3%     +4.4%     +1.2%
       Geometric Mean          -0.1%     -0.3%     -2.9%     -3.0%     +0.0%
      
      On the way I did quite a bit of refactoring in Demand.hs
      9915b656
  31. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Narrow scope of special-case for unqualified printing of names in core libraries · e2c91738
      Ben Gamari authored
      Commit 547c5971 modifies the
      pretty-printer to render names from a set of core packages (`base`,
      `ghc-prim`, `template-haskell`) as unqualified. The idea here was that
      many of these names typically are not in scope but are well-known by the
      user and therefore qualification merely introduces noise.
      
      This, however, is a very large hammer and potentially breaks any
      consumer who relies on parsing GHC output (hence #11208). This commit
      partially reverts this change, now only printing `Constraint` (which
      appears quite often in errors) as unqualified.
      
      Fixes #11208.
      
      Updates tests in `array` submodule.
      
      Test Plan: validate
      
      Reviewers: hvr, thomie, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1619
      
      GHC Trac Issues: #11208
      e2c91738
  32. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  33. 13 Nov, 2015 1 commit
    • Simon Marlow's avatar
      Make 'error' include the CCS call stack when profiled · 8988be85
      Simon Marlow authored
      Summary:
      The idea here is that this gives a more detailed stack trace in two
      cases:
      
      1. With `-prof` and `-fprof-auto`
      2. In GHCi (see #11047)
      
      Example, with an error inserted in nofib/shootout/binary-trees:
      
      ```
      $ ./Main 3
      Main: z
      CallStack (from ImplicitParams):
        error, called at Main.hs:67:29 in main:Main
      CallStack (from -prof):
        Main.check' (Main.hs:(67,1)-(68,82))
        Main.check (Main.hs:63:1-21)
        Main.stretch (Main.hs:32:35-57)
        Main.main.c (Main.hs:32:9-57)
        Main.main (Main.hs:(27,1)-(43,42))
        Main.CAF (<entire-module>)
      ```
      
      This doesn't quite obsolete +RTS -xc, which also attempts to display
      more information in the case when the error is in a CAF, but I'm
      exploring other solutions to that.
      
      Includes submodule updates.
      
      Test Plan: validate
      
      Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1426
      8988be85
  34. 12 Nov, 2015 1 commit
  35. 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