[GHC] #8763: forM_ [1..N] does not get fused (allocates 50% more)
GHC
ghc-devs at haskell.org
Wed Sep 5 08:30:45 UTC 2018
#8763: forM_ [1..N] does not get fused (allocates 50% more)
-------------------------------------+-------------------------------------
Reporter: nh2 | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.8.1
Component: Compiler | Version: 7.6.3
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: #7206 | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
> I didn't know that INLINE works 'both ways', e.g. that we can prevent
inlining the body into c this way.
Yes, it's super-important that INLINE works like that. Consider
{{{
f x = <very big>
g y = Just (f y)
{-# INLINE g #-}
}}}
where that is the only occurrence of `f`, but there are zillions of
occurrences of `g`.
You would be jolly annoyed if GHC inlined `<very big>` into `g`, and then
inlined the new `g` at each of its zillions of call sites!!
No: INLINE says "when you see a saturated application of this function,
inline ''the RHSI wrote'' at the call site".
It might be useful to beef up the documentation of INLINE to explain this,
if you felt able to do so.
I agree that there may be other places such an INLINE would be desirable.
A good start would be a careful Note on `mapM_` explaining from first
principles why the local let and INLINE is important. Then others can
refer to that Note.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763#comment:78>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list