[GHC] #11731: Simplifier: Inlining trivial let can lose sharing
GHC
ghc-devs at haskell.org
Wed Mar 30 16:45:39 UTC 2016
#11731: Simplifier: Inlining trivial let can lose sharing
-------------------------------------+-------------------------------------
Reporter: nomeata | Owner:
Type: bug | Status: patch
Priority: normal | Milestone:
Component: Compiler | Version: 8.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D2064
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
I agreed comment:18 is odd, but first why does "demand information become
something we should try to keep hold on"? What, specifically, goes wrong?
The reasoning here is as follows. Consider
{{{
let f = \xy. x+y
in ...map (f expensive)....
}}}
Now, in `f`'s definition `x` and `y` are both marked
* `OneOcc not-in-lambda` (syntactically occurring once not inside a
lambda; added by the occurrence analyser)
* Demanded (added by the demand analyser)
These annotations assume that `f` is fully applied
But when we inline `f` at this partial application site, we get
{{{
...map (let x = expensive in \y. x+y)...
}}}
and now `x` jolly well shouldn't be marked as occurring not inside a
lambda; nor should it be marked as strictly demanded.
Hence the `zapLamIdInfo`.
What I had forgotten (and has somehow never arisen) is that this ''also''
happens at `f` definition site.
Maybe it doesn't matter. Back to the quesion at the beginning: why does
it matter?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11731#comment:20>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list