[GHC] #11271: Costly let binding gets duplicated in IO action value
GHC
ghc-devs at haskell.org
Mon Dec 21 08:16:26 UTC 2015
#11271: Costly let binding gets duplicated in IO action value
-------------------------------------+-------------------------------------
Reporter: dramforever | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by nomeata):
With 7.8, this is reproducable, but there, `-fno-state-hack` _does_ amend
the problem.
I think the reason is that since 7.10, interface files leak information
about one-shot lambdas. This is intentional, but it means that the effect
of `-fstate-hack` is less local. In particular, in this case, we have this
in the interface of `System.IO`:
{{{
f6fca8f374be656f4987fa89a8843dac
print :: Show a => a -> IO ()
{- Arity: 3, Strictness: <L,1*U(A,1*C1(U),A)><L,U><L,U>,
Unfolding: InlineRule (0, True, True)
print1
`cast`
(forall a. <Show a>_R ->_R <a>_R ->_R Sym (NTCo:IO[0]
<()>_R)) -}
26b6b5cf5870ccc833912748cf8c9456
print1 ::
Show a => a -> State# RealWorld -> (# State# RealWorld, () #)
{- Arity: 3, Strictness: <L,1*U(A,1*C1(U),A)><L,U><L,U>,
Unfolding: InlineRule (3, True, False)
(\ @ a $dShow :: Show a x :: a eta :: State#
RealWorld[OneShot] ->
hPutStr2 stdout (show @ a $dShow x) True eta) -}
}}}
where the real-world argument is marked as `OneShot`. Without digging
deeper, I could imagine that this flag will make GHC believe that the
whole argument to `replicateM_` is one shot and hence inline `ls` into it.
The ideas in #9388 should amend this problem, but I was stalled there by
performance regressions. But maybe we should just take the plunge, get rid
of the state hack in its current form, get a more correct compiler, live
with the performance regressions due to that and try to make up for it in
other ways. Not sure though.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11271#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list