[GHC] #9476: Implement late lambda-lifting
GHC
ghc-devs at haskell.org
Fri Aug 10 15:39:53 UTC 2018
#9476: Implement late lambda-lifting
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: nfrisby
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: #8763 | Differential Rev(s):
Wiki Page: LateLamLift |
-------------------------------------+-------------------------------------
Comment (by sgraf):
I reimplemented this as an STG pass and just rebased it onto a recent 8.6
alpha commit. You can track the progress on my
[https://github.com/sgraf812/ghc/tree/22ce14be00f73b63c24e584dda1ad5e1252e57bd
`lift-lambda` branch, of which this is the current HEAD]. It passes
`./validate`, but due to nofib's `lambda` benchmark not made fit for the
next step of the MonadFail proposal, we can't run benchmarks.
I ran some benchmarks before the rebase, which was relative to
[https://github.com/ghc/ghc/tree/bb539cfe335e this commit]. Here are the
numbers, eliding some uninteresting ones:
{{{
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
VSD -0.3% +0.0%
VSM 0.0% -0.1%
atom -0.8% -1.2%
binary-trees -0.0% -1.5%
circsim -1.0% -0.6%
clausify -1.9% -0.2%
constraints -0.9% -0.7%
cryptarithm1 -2.8% -8.0%
cryptarithm2 -4.0% -2.9%
exact-reals -2.1% -0.1%
fft2 -1.0% -0.4%
fluid -0.9% -0.6%
hidden -1.0% -0.6%
k-nucleotide -0.0% +2.4%
lcss -0.1% -1.3%
mate -3.2% -0.6%
mkhprog -1.3% +1.0%
power -0.7% -1.0%
puzzle -0.0% +0.0%
queens -17.7% -0.9%
reptile -0.3% -17.1%
rewrite -1.7% -0.1%
typecheck -2.7% -1.9%
--------------------------------------------------------------------------------
Min -17.7% -17.1%
Max 0.0% +4.2%
Geometric Mean -0.5% -0.3%
}}}
So, no regressions in allocation (which I'd consider a bug) and some small
gains in general. Note that because of ticket:15333#comment:2 I'm not
really trusting many of the regressions in counted instructions. I'd test
with the proposed `-fllvm -optlo -Os` configuration, but that will have to
wait until nofib is fixed.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9476#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list