[GHC] #9320: Inlining regression/strangeness in 7.8

[GHC]

#9320: Inlining regression/strangeness in 7.8
-------------------------------------+-------------------------------------
              Reporter:  dolio       |             Owner:
                  Type:  bug         |            Status:  new
              Priority:  normal      |         Milestone:
             Component:  Compiler    |           Version:  7.8.2
            Resolution:              |          Keywords:
Differential Revisions:              |  Operating System:  Unknown/Multiple
          Architecture:              |   Type of failure:  Runtime
  Unknown/Multiple                   |  performance bug
            Difficulty:  Unknown     |         Test Case:
            Blocked By:              |          Blocking:
       Related Tickets:              |
-------------------------------------+-------------------------------------

Comment (by dolio):

 Apparently I am not certain. I've conferred with some people, and my
 example displays the same behavior on 7.6.3.

 The intention was to simulate the behavior of the following test:

 {{{
 module Main (main) where

 import qualified Data.Vector.Algorithms.Intro as I
 import qualified Data.Vector.Unboxed as U

 main = do
   let a = U.fromList [0..10000000::Int]
   print (U.length a)
   let k = U.modify (\v -> I.sort v) a
   print (U.length k)
 }}}

 which is an order of magnitude slower on 7.8 than on 7.6 (note, if you
 choose to test this, you must use vector-algorithms 0.6.0.1; I have semi-
 fixed the issue in 0.6.0.2). Running with -ddump-simpl yields 640 lines on
 7.8.{2,3}, and ~4,600 lines on 7.6.3. So clearly the difference involves
 some variety of inlining or specialization.

 The type of {{{sort}}} here is:

 {{{(PrimMonad m, MVector v e, Ord e) => v (PrimState m) e -> m ()}}}

 and the type of {{{modify}}} is:

 {{{Unbox a => (forall s. MVector s a -> ST s ()) -> Vector a -> Vector
 a}}}

 So my aim was to replicate the kind of specialization as the sorting
 example. But clearly I've failed. However, if your description is correct,
 I have no idea why 7.6.3 was inlining/specializing the sort function in
 this example. It has the same open s, necessarily, due to the higher rank
 type of {{{modify}}}. Can you think of anything that might be the
 difference?

 ----

 In another direction, it might be interesting to do the kind of
 specialization you outline above. The {{{PrimMonad}}} dictionary is
 completely determined even though the function is polymorphic in {{{s}}},
 and specializing the function is key to performance, even if some parts
 are still polymorphic (as they necessarily are for {{{ST}}}). Failing to
 unbox all the {{{Int}}} operations and so on merely because we are still
 abstracting over {{{s}}} makes {{{PrimMonad}}} a rather unusable
 abstraction.

 I actually tried (earlier) adding a pragma:

 {{{ {-# SPECIALIZE sort :: MVector s Int -> ST s () #-} }}}

 but GHC complained about it. So it seems that it can't even handle what
 that sort of thing generates, ignoring the fact that it can't generate it
 itself.

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