Re: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing

5 Apr 2016

      ...
The regressions in the two test cases are compiler benchmarks; I think
#11731: Simplifier: Inlining trivial let can lose sharing
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D2073
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 this is the expected cost for another run of the demand analyzer.

 These regressions also happen with a stage1 compiler, and the extra
 allocations correspond quite well to the the numbers shown by the new per-
 pass-numbers. They don’t have deeply nested letrecs, but rather data types
 with lots and lots of record fields.

 Now to `cichelli`. The number of dynamic thunks entered
 (`ENT_DYN_THK_MANY_ctr`) goes down drastically (from 576007 to 115857).
 This is due to `Auxil.$whinsert` getting a strictness signature in its
 first argument, which causes the code
 {{{
   where
   try newAssocs = ( case hinsert (hash newCharAssocs k) keyHashSet of
              Nothing -> (NotEver 1)
 }}}
 in `Prog` to not allocate a thunk for the argument to hinsert, but rather
 evaluate `hash` strictly. The reason the worker `$whinsert` (or rather the
 original `hinsert`) is not stricter earlier is that this is only visible
 after more inlining and case-of-case transformations. So this is nice.

 For mandel2, there are lets (`split_y`) that now have a strict demand and
 thus are compiled differently by the code generator. Nice as well.

 So the effect was not so much due to single entry thunks, but rather due
 to strictness (either via exported signatures and knock-on effects on
 later modules, or via strict lets).

 Does that address the concerns?

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11731#comment:45
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler