1. 12 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Improvements to demand analysis · d77501cd
      Simon Peyton Jones authored
      This patch collects a few improvements triggered by Trac #15696,
      and fixing Trac #16029
      
      * Stop making toCleanDmd behave specially for unlifted types.
        This special case was the cause of stupid behaviour in Trac
        #16029.  And to my joy I discovered the let/app invariant
        rendered it unnecessary.  (Maybe the special case pre-dated
        the let/app invariant.)
      
        Result: less special-case handling in the compiler, and
        better perf for the compiled code.
      
      * In WwLib.mkWWstr_one, treat seqDmd like U(AAA).  It was not
        being so treated before, which again led to stupid code.
      
      * Update and improve Notes
      
      There are .stderr test wibbles because we get slightly different
      strictness signatures for an argumment of unlifted type:
          <L,U> rather than <S,U>        for Int#
          <S,U> rather than <S(S),U(U)>  for Int
      d77501cd
  2. 28 Oct, 2018 1 commit
    • Christiaan Baaij's avatar
      Comment out CONSTANT_FOLDED in GHC.Natural · 2f2308e2
      Christiaan Baaij authored
      Summary:
      Although these functions were marked as CONSTANT_FOLDED, they did
      not have a corresponding builtinRule in PrelRules. The idea was
      probably to add them eventually, but this hasn't manifested so
      far.
      
      The plan is to eventually add builtin rules for these functions
      over Natural, so as a reminder we simply comment out the
      CONSTANT_FOLDED  annotation instead of removing it completely.
      
      Reviewers: hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5267
      2f2308e2
  3. 05 Sep, 2018 1 commit
    • Simon Peyton Jones's avatar
      Preserve specialisations despite CSE · 3addf72a
      Simon Peyton Jones authored
      Trac #15445 showed that, as a result of CSE, a function with an
      automatically generated specialisation RULE could be inlined
      before the RULE had a chance to fire.
      
      This patch attaches a NOINLINE[2] activation to the Id, during
      CSE, to stop this happening.
      
      See Note [Delay inlining after CSE]
      
      ---- Historical note ---
      
      This patch is simpler and more direct than an earlier
      version:
      
        commit 2110738b
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Mon Jul 30 13:43:56 2018 +0100
      
        Don't inline functions with RULES too early
      
      We had to revert this patch because it made GHC itself slower.
      
      Why? It delayed inlining of /all/ functions with RULES, and that was
      very bad in TcFlatten.flatten_ty_con_app
      
      * It delayed inlining of liftM
      * That delayed the unravelling of the recursion in some dictionary
        bindings.
      * That delayed some eta expansion, leaving
           flatten_ty_con_app = \x y. let <stuff> in \z. blah
      * That allowed the float-out pass to put sguff between
        the \y and \z.
      * And that permanently stopped eta expasion of the function,
        even once <stuff> was simplified.
      
      -- End of historical note ---
      3addf72a
  4. 15 Jun, 2018 1 commit
    • Sylvain Henry's avatar
      Built-in Natural literals in Core · fe770c21
      Sylvain Henry authored
      Add support for built-in Natural literals in Core.
      
      - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
        constructor with a LitNumType field
      - Support built-in Natural literals
      - Add desugar warning for negative literals
      - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
        reasons
      
      This patch introduces only a few rules for Natural literals (compared
      to Integer's rules). Factorization of the built-in rules for numeric
      literals will be done in another patch as this one is already big to
      review.
      
      Test Plan:
        validate
        test build with integer-simple
      
      Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
      thomie
      
      GHC Trac Issues: #14170, #14465
      
      Differential Revision: https://phabricator.haskell.org/D4212
      fe770c21
  5. 14 May, 2018 1 commit
  6. 19 Apr, 2018 1 commit
  7. 06 Mar, 2017 1 commit
  8. 28 Feb, 2017 1 commit
  9. 17 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Simplify OutputableBndr · 0e760174
      Simon Peyton Jones authored
      This replaces three methods in OutputableBndr with one,
      and adds comments.
      
      There's also a tiny change in the placement of equals signs in
      debug-prints.  I like it better that way, but if it complicates
      life for anyone we can put it back.
      0e760174
  10. 01 Feb, 2017 1 commit
  11. 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
  12. 06 Apr, 2016 2 commits
  13. 29 Mar, 2016 1 commit
  14. 27 Feb, 2016 1 commit
  15. 18 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactoring on IdInfo and system derived names · ec8a188a
      Simon Peyton Jones authored
      Some modest refactoring, triggered in part by Trac #11051
      
      * Kill off PatSynId, ReflectionId in IdDetails
        They were barely used, and only for pretty-printing
      
      * Add helper function Id.mkExportedVanillaId, and use it
      
      * Polish up OccName.isDerivedOccName, as a predicate for
        definitions generated internally by GHC, which we
        might not want to show to the user.
      
      * Kill off unused OccName.mkDerivedTyConOcc
      
      * Shorten the derived OccNames for newtype and data
        instance axioms
      
      * A bit of related refactoring around newFamInstAxiomName
      ec8a188a
  16. 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
  17. 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
  18. 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
  19. 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
  20. 22 Oct, 2015 1 commit
    • niteria's avatar
      Make stronglyConnCompFromEdgedVertices deterministic · 9cb192ce
      niteria authored
      This makes it so the result of computing SCC's depends on the order
      the nodes were passed to it, but not on the order on the user provided
      key type.
      The key type is usually `Unique` which is known to be nondeterministic.
      
      Test Plan:
      `text` and `aeson` become deterministic after this
      ./validate
      
      Compare compile time for `text`:
      ```
      $ cabal get text && cd text* && cabal sandbox init && cabal install
      --dependencies-only && time cabal build
      real    0m59.459s
      user    0m57.862s
      sys     0m1.185s
      $ cabal clean && time cabal build
      real    1m0.037s
      user    0m58.350s
      sys     0m1.199s
      $ cabal clean && time cabal build
      real    0m57.634s
      user    0m56.118s
      sys     0m1.202s
      $ cabal get text && cd text* && cabal sandbox init && cabal install
      --dependencies-only && time cabal build
      real    0m59.867s
      user    0m58.176s
      sys     0m1.188s
      $ cabal clean && time cabal build
      real    1m0.157s
      user    0m58.622s
      sys     0m1.177s
      $ cabal clean && time cabal build
      real    1m0.950s
      user    0m59.397s
      sys     0m1.083s
      ```
      
      Reviewers: ezyang, simonmar, austin, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1268
      
      GHC Trac Issues: #4012
      9cb192ce
  21. 03 Oct, 2015 1 commit
  22. 16 Jul, 2015 1 commit
  23. 07 Apr, 2015 1 commit
  24. 04 Nov, 2014 1 commit
  25. 28 Aug, 2014 1 commit
    • Simon Peyton Jones's avatar
      Refactor unfoldings · 6e0f6ede
      Simon Peyton Jones authored
      There are two main refactorings here
      
      1.  Move the uf_arity field
             out of CoreUnfolding
             into UnfWhen
          It's a lot tidier there.  If I've got this right, no behaviour
          should change.
      
      2.  Define specUnfolding and use it in DsBinds and Specialise
           a) commons-up some shared code
           b) makes sure that Specialise correctly specialises DFun
              unfoldings (which it didn't before)
      
      The two got put together because both ended up interacting in the
      specialiser.
      
      They cause zero difference to nofib.
      6e0f6ede
  26. 12 Dec, 2013 1 commit
  27. 22 Nov, 2013 2 commits
  28. 03 Oct, 2013 1 commit
  29. 30 Sep, 2013 1 commit
  30. 08 Aug, 2013 1 commit
  31. 01 Aug, 2013 1 commit
  32. 31 Jul, 2013 2 commits