1. 15 Aug, 2019 1 commit
    • James Foster's avatar
      Remove unused imports of the form 'import foo ()' (Fixes #17065) · ca71d551
      James Foster authored
      These kinds of imports are necessary in some cases such as
      importing instances of typeclasses or intentionally creating
      dependencies in the build system, but '-Wunused-imports' can't
      detect when they are no longer needed. This commit removes the
      unused ones currently in the code base (not including test files
      or submodules), with the hope that doing so may increase
      parallelism in the build system by removing unnecessary
      dependencies.
      ca71d551
  2. 01 May, 2019 1 commit
    • Sebastian Graf's avatar
      Compute demand signatures assuming idArity · 014ed644
      Sebastian Graf authored
      This does four things:
      
      1. Look at `idArity` instead of manifest lambdas to decide whether to use LetUp
      2. Compute the strictness signature in LetDown assuming at least `idArity`
         incoming arguments
      3. Remove the special case for trivial RHSs, which is subsumed by 2
      4. Don't perform the W/W split when doing so would eta expand a binding.
         Otherwise we would eta expand PAPs, causing unnecessary churn in the
         Simplifier.
      
      NoFib Results
      
      --------------------------------------------------------------------------------
              Program         Allocs    Instrs
      --------------------------------------------------------------------------------
       fannkuch-redux          +0.3%      0.0%
                   gg          -0.0%     -0.1%
             maillist          +0.2%     +0.2%
              minimax           0.0%     +0.8%
               pretty           0.0%     -0.1%
              reptile          -0.0%     -1.2%
      --------------------------------------------------------------------------------
                  Min          -0.0%     -1.2%
                  Max          +0.3%     +0.8%
       Geometric Mean          +0.0%     -0.0%
      014ed644
  3. 15 Mar, 2019 1 commit
  4. 08 Mar, 2019 1 commit
    • Sebastian Graf's avatar
      Always do the worker/wrapper split for NOINLINEs · 1675d40a
      Sebastian Graf authored
      Trac #10069 revealed that small NOINLINE functions didn't get split
      into worker and wrapper. This was due to `certainlyWillInline`
      saying that any unfoldings with a guidance of `UnfWhen` inline
      unconditionally. That isn't the case for NOINLINE functions, so we
      catch this case earlier now.
      
      Nofib results:
      
      --------------------------------------------------------------------------------
              Program         Allocs    Instrs
      --------------------------------------------------------------------------------
       fannkuch-redux          -0.3%      0.0%
                   gg          +0.0%     +0.1%
             maillist          -0.2%     -0.2%
              minimax           0.0%     -0.8%
      --------------------------------------------------------------------------------
                  Min          -0.3%     -0.8%
                  Max          +0.0%     +0.1%
       Geometric Mean          -0.0%     -0.0%
      
      Fixes #10069.
      
      -------------------------
      Metric Increase:
          T9233
      -------------------------
      1675d40a
  5. 19 Feb, 2019 1 commit
  6. 23 Jan, 2019 1 commit
  7. 22 Nov, 2018 1 commit
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4881
      13bb4bf4
  8. 13 Sep, 2018 1 commit
    • Tobias Dammers's avatar
      Honor INLINE on 0-arity bindings (#15578) · b9b1f999
      Tobias Dammers authored
      Summary:
      Fix test for #15578
      
      By allowing 0-arity values to be inlined, we end up changing boringness
      annotations, and this gets reflected in the Core output for this
      particular test.
      
      Add Notes for #15578
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15578
      
      Differential Revision: https://phabricator.haskell.org/D5137
      b9b1f999
  9. 21 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Simplify callSiteInline a little · 8a05836a
      Simon Peyton Jones authored
      This patch has virtually no effect on anything (according to a
      nofib run).  But it simplifies the definition of interesting_call
      by being a bit less gung-ho about inlining nested function
      bindings.  See Note [Nested functions]
      
      -----------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      -----------------------------------------------------------------------
                 anna          +0.2%     -0.0%     0.163     0.163      0.0%
         binary-trees          +0.1%     +0.0%     -4.5%     -4.5%      0.0%
            cacheprof          -0.1%     +0.1%     -4.7%     -4.8%     +2.7%
                fasta          +0.2%      0.0%     +2.6%     +3.0%      0.0%
                fluid          -0.0%     -0.6%     0.011     0.011      0.0%
               gamteb          -0.1%     -0.0%     0.069     0.070      0.0%
                  hpg          +0.1%     +0.0%     +0.7%     +0.7%      0.0%
                infer          +0.3%     +0.2%     0.097     0.098      0.0%
               lambda          -0.1%     -0.0%     +2.0%     +2.0%      0.0%
               n-body          +0.1%     -0.1%     -0.1%     -0.1%      0.0%
               simple          -0.2%     -0.2%     +0.6%     +0.6%      0.0%
        spectral-norm          +0.1%     -0.0%     -0.1%     -0.1%      0.0%
                  tak          -0.0%     -0.1%     0.024     0.024      0.0%
      --------------------------------------------------------------------------------
                  Min          -0.4%     -0.6%     -5.3%     -5.3%      0.0%
                  Max          +0.3%     +0.2%     +3.3%     +3.3%    +15.0%
       Geometric Mean          -0.0%     -0.0%     -0.3%     -0.3%     +0.2%
      
      (cherry picked from commit 33de71fa)
      
      (This reverts the previous reversion in commit
      9dbf66d7)
      8a05836a
  10. 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
  11. 07 Jun, 2018 2 commits
  12. 15 May, 2018 1 commit
    • Ben Gamari's avatar
      Revert "Simplify callSiteInline a little" · 9dbf66d7
      Ben Gamari authored
      This lead to some rather significant performance regressions.
      Specifically,
      
          bytes allocated value is too high:
              Expected    T5631(normal) bytes allocated: 1106015512 +/-5%
              Lower bound T5631(normal) bytes allocated: 1050714736
              Upper bound T5631(normal) bytes allocated: 1161316288
              Actual      T5631(normal) bytes allocated: 1164953208
              Deviation   T5631(normal) bytes allocated:        5.3 %
          *** unexpected stat test failure for T5631(normal)
          max_bytes_used value is too high:
              Expected    T9630(normal) max_bytes_used: 35324712 +/-15%
              Lower bound T9630(normal) max_bytes_used: 30026005
              Upper bound T9630(normal) max_bytes_used: 40623419
              Actual      T9630(normal) max_bytes_used: 43490984
              Deviation   T9630(normal) max_bytes_used:     23.1 %
          *** unexpected stat test failure for T9630(normal)
      
      This reverts commit 7271db46.
      This reverts commit b750dcc5.
      This reverts commit 33de71fa.
      9dbf66d7
  13. 04 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Simplify callSiteInline a little · 33de71fa
      Simon Peyton Jones authored
      This patch has virtually no effect on anything (according to a
      nofib run).  But it simplifies the definition of interesting_call
      by being a bit less gung-ho about inlining nested function
      bindings.  See Note [Nested functions]
      
      -----------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      -----------------------------------------------------------------------
                 anna          +0.2%     -0.0%     0.163     0.163      0.0%
         binary-trees          +0.1%     +0.0%     -4.5%     -4.5%      0.0%
            cacheprof          -0.1%     +0.1%     -4.7%     -4.8%     +2.7%
                fasta          +0.2%      0.0%     +2.6%     +3.0%      0.0%
                fluid          -0.0%     -0.6%     0.011     0.011      0.0%
               gamteb          -0.1%     -0.0%     0.069     0.070      0.0%
                  hpg          +0.1%     +0.0%     +0.7%     +0.7%      0.0%
                infer          +0.3%     +0.2%     0.097     0.098      0.0%
               lambda          -0.1%     -0.0%     +2.0%     +2.0%      0.0%
               n-body          +0.1%     -0.1%     -0.1%     -0.1%      0.0%
               simple          -0.2%     -0.2%     +0.6%     +0.6%      0.0%
        spectral-norm          +0.1%     -0.0%     -0.1%     -0.1%      0.0%
                  tak          -0.0%     -0.1%     0.024     0.024      0.0%
      --------------------------------------------------------------------------------
                  Min          -0.4%     -0.6%     -5.3%     -5.3%      0.0%
                  Max          +0.3%     +0.2%     +3.3%     +3.3%    +15.0%
       Geometric Mean          -0.0%     -0.0%     -0.3%     -0.3%     +0.2%
      33de71fa
  14. 26 Mar, 2018 1 commit
    • Ben Gamari's avatar
      Add new debugging flag -dinline-check · ecfb4d36
      Ben Gamari authored
      This flag reports a summary of the inlining decision for identifiers
      prefixed by the flag's argument.
      
      For example, `-dinline-check foo` will report why definitions whose
      prefix is `foo` are inlined or not.
      
      Previously the only way to get this information was to pass a
      combination of `-dverbose-core2core` and `-ddump-inlinings`.
      
      This combination led to a log of 12 million lines in a module of about
      200 lines I recently had to apply it to. This flag provides a much more
      direct way to find the occurence you care about.
      
      Reviewers: osa1, dfeuer, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4458
      ecfb4d36
  15. 25 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix the lone-variable case in callSiteInline · 06366890
      Simon Peyton Jones authored
      See Note [Lone variables] in CoreUnfold and
      Note [exprIsExpandable] in CoreUtils.
      
      Helpfully pointed out by Matthew Pickering in Trac #14688
      
      Nofib results are good:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                 anna          +0.1%     +0.3%     0.151     0.151      0.0%
               awards          +0.0%     -0.2%     0.001     0.001      0.0%
            compress2          +0.6%     -0.7%     -4.8%     -5.0%     -4.0%
                eliza          +0.0%     -2.4%     0.001     0.001      0.0%
               fulsom          +0.4%    -13.3%     -7.6%     -7.6%   +190.0%
               gamteb          +0.0%     -0.6%     0.062     0.062      0.0%
                   gg          +0.1%     -0.4%     0.016     0.016      0.0%
                  ida          +0.1%     +0.3%     0.110     0.110      0.0%
                kahan          +0.0%     -0.7%     -0.9%     -0.9%      0.0%
                 mate          +0.1%     -5.2%     -4.9%     -4.9%      0.0%
               n-body          +0.0%     -0.2%     -0.3%     -3.0%      0.0%
               pretty          +0.0%     -2.8%     0.000     0.000      0.0%
                  scs          +0.0%     -0.2%     +1.6%     +2.4%      0.0%
               simple          +0.4%     -0.2%     -2.3%     -2.3%     -3.4%
              veritas          +0.4%     -1.0%     0.003     0.003      0.0%
                 wang          +0.0%     -1.6%     0.165     0.165      0.0%
      --------------------------------------------------------------------------------
                  Min          -0.0%    -13.3%    -16.2%    -18.8%     -4.0%
                  Max          +0.6%     +0.3%     +4.9%     +4.9%   +190.0%
       Geometric Mean          +0.1%     -0.3%     -1.7%     -2.4%     +0.9%
      06366890
  16. 26 Sep, 2017 1 commit
  17. 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
  18. 20 Jul, 2017 1 commit
  19. 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
  20. 28 Apr, 2017 1 commit
  21. 17 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      No join-point from an INLINE function with wrong arity · a7dbafe9
      Simon Peyton Jones authored
      The main payload of this patch is NOT to make a join-point
      from a function with an INLINE pragma and the wrong arity;
      see Note [Join points and INLINE pragmas] in CoreOpt.
      This is what caused Trac #13413.
      
      But we must do the exact same thing in simpleOptExpr,
      which drove me to the following refactoring:
      
      * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new
        module CoreOpt along with a few others (exprIsConApp_maybe,
        pushCoArg, etc)
      
        This eliminates a module loop altogether (delete
        CoreArity.hs-boot), and stops CoreSubst getting too huge.
      
      * Rename Simplify.matchOrConvertToJoinPoint
           to joinPointBinding_maybe
        Move it to the new CoreOpt
        Use it in simpleOptExpr as well as in Simplify
      
      * Define CoreArity.joinRhsArity and use it
      a7dbafe9
  22. 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
  23. 06 Mar, 2017 1 commit
  24. 28 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Small changes to expression sizing in CoreUnfold · c662d41e
      Simon Peyton Jones authored
      The only significant change here is that
      
         case e of {}
      
      should be treated like 'e', rather than like a case expression.
      We don't push a return address, for example, since 'e' is sure to
      diverge.
      
      I forget why I did this; but it will make these empty-case expressions
      (which are only there to satisfy the type checker) cost-free.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3204
      c662d41e
  25. 23 Feb, 2017 1 commit
  26. 08 Feb, 2017 1 commit
  27. 07 Feb, 2017 2 commits
    • Simon Peyton Jones's avatar
      Comments only · f77e99bb
      Simon Peyton Jones authored
      f77e99bb
    • Simon Peyton Jones's avatar
      Do not inline bottoming things · a0174d22
      Simon Peyton Jones authored
      If a function seems small, worker/wrapper won't split it; instead
      it turns it into an INLINE function.
      
      But if it's a /bottoming/ function that's a bad idea.  We want
      don't want to inline bottoming functions unless they are /really/
      small (smaller than the call itself) and that's handled by a
      different branch in certainlyWillInline.
      
      So this patch adds a not-bottom test to the UnfIfGoodArgs case of
      certainlyWillInline.
      
      No big perf effect, but this will tend to keep error code out of
      functions, and hence make them a bit more likely to inline.
      
      I fell over this when fiddling with #13144
      a0174d22
  28. 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
  29. 04 Feb, 2017 1 commit
  30. 01 Feb, 2017 1 commit
  31. 23 Jan, 2017 1 commit
  32. 18 Jan, 2017 1 commit
  33. 17 Jan, 2017 1 commit
    • David Feuer's avatar
      Split mkInlineUnfolding into two functions · d360ec39
      David Feuer authored
      Previously, `mkInlineUnfolding` took a `Maybe` argument indicating
      whether the caller requested a specific arity.  This was not
      self-documenting at call sites. Now we distinguish between
      `mkInlineUnfolding` and `mkInlineUnfoldingWithArity`.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2933
      d360ec39
  34. 23 Dec, 2016 1 commit
    • Simon Peyton Jones's avatar
      Ensure that even bottoming functions have an unfolding · 11306d62
      Simon Peyton Jones authored
      The payload of this change is to ensure that a bottoming function
      still has an unfolding, just one with an UnfoldingGuidance of
      UnfoldNever.
      
      Previously it was getting an unfolding of NoUnfolding. I don't think
      that was really /wrong/, but it was inconsistent with the general
      principle of giving everthing an unfoding if we know it.  And it
      seems tideier this way.
      11306d62
  35. 21 Dec, 2016 2 commits
    • Simon Peyton Jones's avatar
      Fix 'SPECIALISE instance' · 1a4c04b1
      Simon Peyton Jones authored
      Trac #12944 showed that the DsBinds code that implemented a
      SPECIALISE pragma was inadequate if the constraints solving
      added let-bindings for dictionaries.  The result was that
      we ended up with an unbound dictionary in a DFunUnfolding -- and
      Lint didn't even check for that!
      
      Fixing this was not entirely straightforward
      
      * In DsBinds.dsSpec we use a new function
           TcEvidence.collectHsWrapBinders
        to pick off the lambda binders from the HsWapper
      
      * dsWrapper now returns a (CoreExpr -> CoreExpr) function
      
      * CoreUnfold.specUnfolding now takes a (CoreExpr -> CoreExpr)
        function it can use to specialise the unfolding.
      
      On the whole the code is simpler than before.
      1a4c04b1
    • Simon Peyton Jones's avatar
      Never apply worker/wrapper to DFuns · c48595ee
      Simon Peyton Jones authored
      While fixing Trac #12444 I found an occasion on which we applied
      worker/wrapper to a DFunId.  This is bad: it destroys the magic
      DFunUnfolding.
      
      This patch is a minor refactoring that stops this corner case
      happening, and tidies up the code a bit too.
      c48595ee
  36. 24 Sep, 2016 1 commit
    • Joachim Breitner's avatar
      Replace INLINEABLE by INLINABLE (#12613) · 68f72f10
      Joachim Breitner authored
      as the latter is the official, correct spelling, and the former just a
      misspelling accepted by GHC.
      
      Also document in the user’s guide that the alternative spelling is
      accepted
      
      This commit was brough to you by HIW 2016.
      68f72f10
  37. 21 Aug, 2016 1 commit