[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