#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