[commit: ghc] wip/T14068: Implement loopification for local bindings (#14068) (8469ddd)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : wip/T14068
Link       : http://ghc.haskell.org/trac/ghc/changeset/8469ddd712612767a2b6c5cea8c24f7b1e9561ff/ghc

>---------------------------------------------------------------

commit 8469ddd712612767a2b6c5cea8c24f7b1e9561ff
Author: Joachim Breitner <mail at joachim-breitner.de>
Date:   Tue Aug 1 09:47:49 2017 -0400

    Implement loopification for local bindings (#14068)
    
    This is a relatively prelimary version. I am sure there is a huge number
    of invariants that this breaks, and conditions that I am not checking
    etc. I do not even know if the simplifier is the right place to
    implement this.
    
    But it works in this simple case:
    
        module T14068 where
        foo p f k =
          let bar a = if p a then bar (f a) else a
          in k bar
    
    so we can iterate from here.
    
    The IdInfo of a loopified binder stays with the outer binder, e.g.
    RULES should stay unaffected.
    
    The local binder gets localised.
    
    During loopification, we zap occurrence info on the lambda binders
    
    If we have
    
      letrec f x[dead] = … f () …
      in g f
    
    loopification turns that into
    
      let f x = joinrec f x[dead] = … f () …
                in jump j x
      in g f
    
    Note that the parameter x of f is no longer dead!
    
    Disable test case for #4030 and #5644
    
    With loopification, T4030 always goes into an infinite loop. Not nice when
    running the test suite.
    
    Also, with loopification, T5644 no longer runs out of heap, so it does
    not trigger the out-of-heap exception that the test case was testing.
    
    Mark `eqString` as `NOINLINE`
    so that the built-in rule can still match.
    
    This will be a problem in general: With loopification, recursive
    functions can now inline (yay!) but many people out there probably rely
    on the fact that recursive functions cannot inline (ouch). Hopefully the
    recent warnings in GHC made them fix this before loopification reaches
    them.
    
    Do not inline showWord
    
    mostly because otherwise the test setup of #7014 fails.
    (The test checks for the absence of certain primops in the code, but
    inlining showWords adds many of these.)
    
    Make the test case for #T5949 a little less bogus
    
    by actually using the result of `e`. I *believe* it still tests what we
    want to test, and now we get proper results with loopification.
    
    I am not so worried about the regression in the case of an unused result
    of `e`.


>---------------------------------------------------------------

8469ddd712612767a2b6c5cea8c24f7b1e9561ff
 compiler/basicTypes/BasicTypes.hs           | 28 +++++++++++++-----
 compiler/basicTypes/IdInfo.hs               |  4 +--
 compiler/coreSyn/CoreOpt.hs                 | 45 ++++++++++++++++++++++++-----
 compiler/simplCore/OccurAnal.hs             | 29 ++++++++++++++++---
 compiler/simplCore/Simplify.hs              | 28 +++++++++++++++++-
 compiler/types/Type.hs                      | 40 +++++++++++++------------
 testsuite/tests/concurrent/should_run/all.T |  4 ++-
 testsuite/tests/perf/should_run/T5949.hs    |  2 +-
 testsuite/tests/rts/T5644/ManyQueue.hs      |  0
 testsuite/tests/rts/T5644/all.T             |  4 ++-
 10 files changed, 141 insertions(+), 43 deletions(-)

Diff suppressed because of size. To see it, use:

    git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc 8469ddd712612767a2b6c5cea8c24f7b1e9561ff