#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.
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
Replying to [comment:14 batterseapower]: 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