[GHC] #7782: flag to run the demand analysis a second time
GHC
cvs-ghc at haskell.org
Thu Mar 21 18:17:04 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 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 (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.
--
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7782#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list