[GHC] #4941: SpecConstr generates functions that do not use their arguments

[GHC]

#4941: SpecConstr generates functions that do not use their arguments
---------------------------------+------------------------------------------
    Reporter:  simonpj           |       Owner:                         
        Type:  task              |      Status:  new                    
    Priority:  normal            |   Milestone:  _|_                    
   Component:  Compiler          |     Version:  7.0.1                  
    Keywords:                    |          Os:  Unknown/Multiple       
Architecture:  Unknown/Multiple  |     Failure:  Runtime performance bug
  Difficulty:                    |    Testcase:                         
   Blockedby:                    |    Blocking:                         
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by nfrisby):

 Replying to [comment:9 batterseapower]:
 > I looked at the worst offender (crypytarithm2) and saw something pretty
 odd. It looks like the transformation is working correctly but the output
 code (post simplification) contains dead let-bindings for SpecConstr
 specialisations that have been worker/wrappered, and those workers have
 been subsequently inlined into all use sites.

 Replying to [comment:14 batterseapower]:
 > I fail to see how this does not explain the allocation increase - if my
 inner loop is allocating a spurious closure for this dead function,
 doesn't that increase the allocation figures? The dead function is not
 present in the version of the code without the extra strictness analysis
 pass.

 These dead SpecConstr'd and ww'd closures are still allocated in
 cryptarithm2.

 With the late demand, cryptarithm2 has +8% allocation. These dead closures
 are 4% of that (according to ticky). The other 4% is reboxing: 3 words, ~
 4000 times --- for calls to those dead lets' progeny, no less.

 I used the pipeline: SpecConstr, simpl, stranal, wwsplit, simpl.

 I have confirmed that the variables are dead in the STG.

 I have not investigated why the fix for #4962 doesn't remove these lets.

 I altered ticky to count the heap used when allocating each closure.

 {{{
     Entries     Allocs    Alloc'd  Arity  Kinds        Function
 --------------------------------------------------------------------------------
           0          0       2056      3    SSL        $sgo{v s2X7}
 (main:Main)
           0          0       8262      3    SSL        $sgo{v s2Qx}
 (main:Main)
           0          0      13460      3    ESL        $sgo1{v s2Zq}
 (main:Main)
           0          0      25288      3    ESL        $sgo1{v s2R0}
 (main:Main)
           0          0      75814      3    SSL        $sgo{v s2Ui}
 (main:Main)

 3376149 ALLOC_HEAP_tot
 }}}

 With just -O2, it's 3125158 ALLOC_HEAP_tot.

 Otherwise, the late demand looks pretty good. Column header = <libraries
 options>/<nofib test options>. ____ is 0.0%. In this notation, "late-dmd"
 implies also -O2.

 {{{
 Allocations

 -------------------------------------------------------------------------------
         Program                O2/O2     late-dmd/O2    late-dmd/late-dmd
 -------------------------------------------------------------------------------
    cryptarithm2             25078168           +____           +8.0%
        nucleic2             98331744           +____           +3.2%

        cichelli             80310632           +____          -22.9%
           fasta            401159024           -9.1%           -9.1%
          fulsom            321427240           +____           -2.6%
    k-nucleotide           4125102928           -____           -4.8%
         knights              2037984           +____           -3.7%
         mandel2              1041840           +____          -21.4%
         parstof              3103208           +____           -1.4%
 reverse-complem            155188304          -12.8%          -12.8%
          simple            226412800           -____           -1.0%
 }}}

 I'm investigating nucleic2 at the moment; it's changing something
 currently not specifically tracked by ticky, so I'm resurrecting more
 counters. There's nothing obvious to me in the STG, at least.

 I don't yet have trustworthy runtime numbers.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4941#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler