[commit: ghc] master: Record evaluated-ness on workers and wrappers (596dece)

[git at git.haskell.org]

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

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/596dece7866006d699969f775fd97bd306aad85b/ghc

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

commit 596dece7866006d699969f775fd97bd306aad85b
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Fri Jan 13 08:56:53 2017 +0000

    Record evaluated-ness on workers and wrappers
    
    Summary:
    This patch is a refinement of the original commit (which
    was reverted):
    
      commit 6b976eb89fe72827f226506d16d3721ba4e28bab
      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%


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

596dece7866006d699969f775fd97bd306aad85b
 compiler/basicTypes/Id.hs                         |  13 ++-
 compiler/basicTypes/IdInfo.hs                     |  18 +++-
 compiler/coreSyn/CoreSubst.hs                     |  12 ++-
 compiler/coreSyn/CoreSyn.hs                       |  36 ++++++--
 compiler/coreSyn/CoreUtils.hs                     |   6 +-
 compiler/simplCore/Simplify.hs                    |  16 ++--
 compiler/stranal/WwLib.hs                         | 108 +++++++++++++++++-----
 testsuite/tests/perf/compiler/all.T               |   5 +-
 testsuite/tests/stranal/should_compile/T13077.hs  |  15 +++
 testsuite/tests/stranal/should_compile/T13077a.hs |  21 +++++
 testsuite/tests/stranal/should_compile/all.T      |   3 +-
 11 files changed, 192 insertions(+), 61 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 596dece7866006d699969f775fd97bd306aad85b