[GHC] #10371: GHC fails to inline and specialize a function

1 May 2015

      #10371: GHC fails to inline and specialize a function
-------------------------------------+-------------------------------------
              Reporter:              |             Owner:
  MikeIzbicki                        |            Status:  new
                  Type:  bug         |         Milestone:
              Priority:  normal      |           Version:  7.10.1
             Component:  Compiler    |  Operating System:  Unknown/Multiple
              Keywords:              |   Type of failure:  None/Unknown
          Architecture:              |        Blocked By:
  Unknown/Multiple                   |   Related Tickets:
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
 I have an alternative Prelude library called
 [subhask](https://github.com/mikeizbicki/subhask) that redefines the
 numeric type class hierarchy.  I'm trying to update it to work with GHC
 7.10, but there is a major inlining bug that is killing performance.

 The code below demonstrates the issue.  It first defines a distance
 function over 2 vectors, then measures the performance using criterion.
 (It requires the subhask to compile.)

 {{{
 {-# LANGUAGE BangPatterns #-}

 import Control.DeepSeq
 import Criterion.Main
 import qualified Data.Vector.Unboxed as VU
 import qualified Data.Vector.Generic as VG

 import qualified Prelude
 import SubHask

 -- distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float
 distance_standalone v1 v2 = sqrt $ go 0 0
     where
         go !tot !i =  if i>VG.length v1-4
             then goEach tot i
             else go tot' (i+4)
             where
                 tot' = tot
                     +(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i)
                     *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i)
                     +(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1))
                     *(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1))
                     +(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2))
                     *(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2))
                     +(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3))
                     *(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3))

         goEach !tot !i = if i>= VG.length v1
             then tot
             else goEach tot' (i+1)
             where
                 tot' = tot+(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i)
                           *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i)

 main = do
     let v1 = VU.fromList [1..200] :: VU.Vector Float
         v2 = VU.fromList [1..200] :: VU.Vector Float

     deepseq v1 $ deepseq v2 $ return ()

     defaultMain
         [ bench "distance_standalone" $ nf (distance_standalone v1) v2
         ]

 }}}

 Here are the results of compiling and running using GHC 7.10 and 7.8:

 {{{
 $ ghc-7.10.1 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl &&
 ./Main
 [1 of 1] Compiling Main             ( Main.hs, Main.o )
 Linking Main ...
 benchmarking distance_standalone
 time                 8.135 μs   (8.121 μs .. 8.154 μs)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 8.188 μs   (8.158 μs .. 8.250 μs)
 std dev              139.3 ns   (66.05 ns .. 250.4 ns)
 variance introduced by outliers: 15% (moderately inflated)
 }}}

 {{{
 $ ghc-7.8.2 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl &&
 ./Main
 [1 of 1] Compiling Main             ( Main.hs, Main.o )
 Linking Main ...
 benchmarking distance_standalone
 time                 733.2 ns   (732.9 ns .. 733.6 ns)
                      1.000 R²   (1.000 R² .. 1.000 R²)
 mean                 734.1 ns   (733.7 ns .. 734.5 ns)
 std dev              1.458 ns   (1.262 ns .. 1.754 ns)
 }}}

 As you can see, GHC 7.10 is 10x slower.  Looking through the core output
 shows that the cause of this is that GHC 7.8 is properly specializing the
 code whereas GHC 7.10 is not.  If you uncomment the type signature before
 the `distance_standalone` function then both compilers perform at the
 faster speed.

 I believe the cause of this may be related to the complicated class
 numeric class hierarchy in SubHask.  If you comment out the lines:

 {{{
 import qualified Prelude
 import SubHask
 }}}

 then GHC uses the Prelude hierarchy instead of SubHask's hierarchy, and
 both compilers generate the faster program.

 There's one last wrinkle.  If you define the `distance_standalone`
 function in a different file.  Then in GHC 7.10, the `INLINE` and
 `INLINABLE` pragmas do absolutely nothing.  Not only does the resulting
 code not get inlined, but if I add the specialization:
 {{{
 {-# SPECIALIZE distance_standalone :: VU.Vector Float -> VU.Vector Float
 -> Float #-}
 }}}
 to the Main file, I get an error message saying something like:
 {{{
 bench/Vector.hs:18:1: Warning:
     You cannot SPECIALISE ‘distance_standalone{v ru1}’
       because its definition has no INLINE/INLINABLE pragma
       (or its defining module
 ‘subhask-0.1.0.0@subha_LNZiQvSbo8Z0VdLTwuvkrN:SubHask.Algebra’
        was compiled without -O)
 }}}
 I get this message despite the fact that the defining module was compiled
 with `-O2` and the function had an `INLINABLE` pragma.  If I add the
 specialization pragma to the defining module, then I don't get the
 warning, but the code still doesn't specialize properly.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10371
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler