GitLab

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.

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%

This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.

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
-------------------------

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

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

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)

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

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4775

This plumbs DynFlags through CoreOpt so optCoercion can finally
eliminate its usage of `unsafeGlobalDynFlags`.

Note that this doesn't completely eliminate `unsafeGlobalDynFlags`
usage from this bit of the compiler. A few uses are introduced in
call-sites where we don't (yet) have ready access to `DynFlags`.

Test Plan: Validate

Reviewers: goldfire

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4774

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.

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%

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

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%

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

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

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

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.

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

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

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

This flag overrides the inliner heuristics to inline something
independent of cost, size, expected gains or boringness of the context.

It still adheres to arity, simplifier phase control and loop breakers.

This is not exposed via a command line flag and added for the benefit of
GHC API users.

Differential Revision: https://phabricator.haskell.org/D3069

This major patch implements Join Points, as described in
https://ghc.haskell.org/trac/ghc/wiki/SequentCore.  You have
to read that page, and especially the paper it links to, to
understand what's going on; but it is very cool.

It's Luke Maurer's work, but done in close collaboration with Simon PJ.

This Phab is a squash-merge of wip/join-points branch of
http://github.com/lukemaurer/ghc. There are many, many interdependent
changes.

Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin

Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie

Differential Revision: https://phabricator.haskell.org/D2853

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

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.

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.

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.

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.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2246