[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)

[GHC]

#8763: forM_ [1..N] does not get fused (10 times slower than go function)
--------------------------------------------+------------------------------
        Reporter:  nh2                      |            Owner:
            Type:  bug                      |           Status:  new
        Priority:  normal                   |        Milestone:
       Component:  Compiler                 |          Version:  7.6.3
      Resolution:                           |         Keywords:
Operating System:  Unknown/Multiple         |     Architecture:
 Type of failure:  Runtime performance bug  |  Unknown/Multiple
       Test Case:                           |       Difficulty:  Unknown
        Blocking:                           |       Blocked By:
                                            |  Related Tickets:
--------------------------------------------+------------------------------

Comment (by daniel.is.fischer):

 Replying to [comment:8 nh2]:
 > I have updated the gist at https://gist.github.com/nh2/11333427 to
 contain both the matmult example (where the difference between `forM_` and
 `loop` is big) and the simple example (where no difference can be
 measured).

 The simple example doesn't use the same list in different places, so GHC
 is capable of eliminating it and giving you a loop on unboxed `Int#`s, at
 least with `-O2`. In the matmult example, you need to conceal the fact
 that both lists are the same from GHC to get a loop on unboxed `Int#`s.

 So in principle, GHC can do the desired thing, just the sharing gets in
 the way. Can somebody think of a situation where sharing is beneficial for
 `forM_ [a .. b] $ \n -> do ...` code? If not, perhaps special-casing
 `enumFromTo` arguments for `forM_` etc. is, at least for standard integer
 types, something to be considered.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler