[GHC] #14827: Recognize when inlining would create a join point

[GHC]

#14827: Recognize when inlining would create a join point
-------------------------------------+-------------------------------------
        Reporter:  ersetzen          |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:  JoinPoints
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 ersetzen):

 Oh, you are right, this totally falls under loopification. Curiously
 enough wip/T14068 doesn't solve this, though. I think it gets stuck at the
 `inline f step`. Here an excerpt of the
 [https://gist.github.com/Tarmean/5d423b454dd75f8db11505eb28841ad1
 simplifier dump].
 I was always under the impression that non-recursive let bound variables
 that are used exactly once (which is the case here) are inlined
 unconditionally but that doesn't happen here.

 [https://gist.github.com/Tarmean/6edf2153806434e688d1fd77964248ed Here is
 a slightly more inlined version]. Removing `{-# INLINE indices #-}` allows
 buildTable to be inlined which removes the call.
 Looking at the cmm, scan saves and restors 96 bytes of data when calling
 buildTable so that might be a large part of the performance drop?

 Side note: Neither the loopification branch and ghc head run faster with
 ghci.

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