[GHC] #7782: flag to run the demand analysis a second time

GHC cvs-ghc at haskell.org
Thu Mar 21 18:19:06 CET 2013


#7782: flag to run the demand analysis a second time
-------------------------------------------+--------------------------------
    Reporter:  nfrisby                     |       Owner:                  
        Type:  task                        |      Status:  new             
    Priority:  normal                      |   Milestone:                  
   Component:  Compiler                    |     Version:  7.7             
    Keywords:                              |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple            |     Failure:  None/Unknown    
  Difficulty:  Unknown                     |    Testcase:                  
   Blockedby:                              |    Blocking:                  
     Related:  #4941, #5302, #6087, #4962  |  
-------------------------------------------+--------------------------------
Description changed by simonpj:

Old description:

> There are some tickets documenting runtime bugs that can be cleaned up by
> running the demand analyzer (followed by a simplifier run) a second time
> at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?
>
> Here's the effects on nofib. Run time didn't seem to change as
> drastically.  The "X/Y" column headers mean "library-flags/test-flags"
> given to GHC when compiling the respective bit.
>
> {{{
> Allocations
>
> -------------------------------------------------------------------------------
>         Program                O2/O2     late-dmd+O2/O2    late-dmd+O2
> /late-dmd+O2
> -------------------------------------------------------------------------------
>    cryptarithm2             25078168           +0.0%           +8.0%
>        nucleic2             98331744           +0.0%           +3.2%
>
>        cichelli             80310632           +0.0%          -22.9%
>           fasta            401159024           -9.1%           -9.1%
>          fulsom            321427240           +0.0%           -2.6%
>    k-nucleotide           4125102928           -0.0%           -4.8%
>         knights              2037984           +0.0%           -3.7%
>         mandel2              1041840           +0.0%          -21.4%
>         parstof              3103208           +0.0%           -1.4%
> reverse-complem            155188304          -12.8%          -12.8%
>          simple            226412800           -0.0%           -1.0%
> }}}
>
> Note that it improves a couple tests significantly just via changes in
> the base libraries.
>
> For cryptarithm2, (cf remarks in #4941)
>  * 4% increase allocation is due to reboxing
>  * 4% is due to dead closures, because the fix in #4962 isn't working for
> some reason.
>
> For nucleic2, in var_most_distant_atom, an let-bound function is inlined
> after w/w, and hence grows numerous closures by a significant amount. I'm
> not sure where to lay the blame for this. Note however, that just making
> nucleic2's data types use strict !Float fields changes its allocation
> -72.4%, so maybe this "bad practice" corner case is a small issue.
>
> The main remaining task beyond the attached patch is to repair the
> treatment of wrapper's strictness signatures in .hi files. Because the
> second demand analysis might change a these signatures, the current
> compaction mechanism that .hi uses results in ill-formed Core. For the
> attached patch, I've just disabled that .hi compaction mechanism, but
> this just needlessly bloats .hi files.

New description:

 There are some tickets documenting runtime bugs that can be cleaned up by
 running the demand analyzer (followed by a simplifier run) a second time
 at the end of the pipeline: #4941, #5302, #6087. #6070 ? Others?

 Here's the effects on nofib. Run time didn't seem to change as
 drastically.  The "X/Y" column headers mean "library-flags/test-flags"
 given to GHC when compiling the respective bit.

 {{{
 Allocations

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

        cichelli             80310632           +0.0%          -22.9%
           fasta            401159024           -9.1%           -9.1%
          fulsom            321427240           +0.0%           -2.6%
    k-nucleotide           4125102928           -0.0%           -4.8%
         knights              2037984           +0.0%           -3.7%
         mandel2              1041840           +0.0%          -21.4%
         parstof              3103208           +0.0%           -1.4%
 reverse-complem            155188304          -12.8%          -12.8%
          simple            226412800           -0.0%           -1.0%
 }}}
 All other changes less than 1% allocation.
 Note that it improves a couple tests significantly just via changes in the
 base libraries.

 For cryptarithm2, (cf remarks in #4941)
  * 4% increase allocation is due to reboxing
  * 4% is due to dead closures, because the fix in #4962 isn't working for
 some reason.

 For nucleic2, in var_most_distant_atom, an let-bound function is inlined
 after w/w, and hence grows numerous closures by a significant amount. I'm
 not sure where to lay the blame for this. Note however, that just making
 nucleic2's data types use strict !Float fields changes its allocation
 -72.4%, so maybe this "bad practice" corner case is a small issue.

 The main remaining task beyond the attached patch is to repair the
 treatment of wrapper's strictness signatures in .hi files. Because the
 second demand analysis might change a these signatures, the current
 compaction mechanism that .hi uses results in ill-formed Core. For the
 attached patch, I've just disabled that .hi compaction mechanism, but this
 just needlessly bloats .hi files.

--

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



More information about the ghc-tickets mailing list