Re: [GHC] #14068: Loopification using join points

23 Feb 2018

      #14068: Loopification using join points
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:  nomeata
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:  JoinPoints
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #13966 #14067     |  Differential Rev(s):  Phab:D3811
  #14827                             |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by sgraf):

 As to why

 {{{
 drop n xs =
   joinrec j n xs = case xs of
     []     -> []
     (y:ys) -> case n of
        I# n# -> case n# of
          0# -> []
          _ -> call j (I# (n# -# 1#)) xs
   in j n xs
 }}}

 specializes to

 {{{
 drop n xs =
   case xs of
     []     -> []
     (y:ys) -> case n of
        I# n# -> case n# of
          0# -> []
          _ ->
            joinrec j xs n# = case xs of
               []     -> []
               (y:ys) -> case n# of
                  0# -> []
                  _ -> call j ys (n# -# 1#)
            in j ys (n# -# 1#)
 }}}

 There is the call pattern `j (I# (n# -# 1#)) xs`, also `j` scrutinizes
 `n`. So SpecConstr makes something like this:

 {{{
 drop n xs =
   joinrec
   j n xs = case xs of
     []     -> []
     (y:ys) -> case n of
        I# n# -> case n# of
          0# -> []
          _ -> call j# (n# -# 1#) xs

   j# n# xs = case xs of
     []     -> []
     (y:ys) -> case n# of
          0# -> []
          _ -> call j# (n# -# 1#) xs
   in j n xs
 }}}

 Now `j` is not recursive and is inlined and we get the resulting code.

 I wonder why `drop` isn't inlined in your example. That would surely make
 the allocation go away? Are there multiple calls to `drop` that obstruct
 inlining?

 And if so, do they share a common call pattern (e.g. `j (I# n) xs`)? Then
 that's one of the cases non-rec specialisation might be beneficial.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14068#comment:39
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler