#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 | -------------------------------------------+-------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description:
There are some tickets documenting runtime bugs that can be cleaned up by running the demand analyzer 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.
{{{ Allocations
------------------------------------------------------------------------------- Program O2/O2 late-dmd/O2 late-dmd/late-dmd ------------------------------------------------------------------------------- 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, see my comments on #4941. This might indicate that #4962 should be re-opened.
For nucleic2, in var_most_distant_atom, an inlined let 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 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 late-dmd/late-dmd ------------------------------------------------------------------------------- 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, see my comments on #4941. This might indicate that #4962 should be re-opened. For nucleic2, in var_most_distant_atom, an inlined let 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:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler