Too many specialisations in SpecConstr

[simonpj]

Ben reports that SpecConstr can loop:

{-# LANGUAGE PArr #-}
{-# OPTIONS -fvectorise #-}

module Loop where
import Data.Array.Parallel.Prelude
import Data.Array.Parallel.Prelude.Double
import qualified Prelude

loop :: [:Double:] -> [:Double:]
loop xs 
    | 0 == 0    = xs
    | otherwise     = ([::] !: 0) +:+ [::] +:+ ([::] !: 0)

Compile with

~/devel/ghc/ghc-head-incoming/inplace/bin/ghc-stage2 -c -Odph -fdph-seq -package dph-seq -package dph-prim-seq -c Loop.hs

(You need to build the DPH libraries first, of course.) This causes SpecConstr to loop for at least 5 mins on my machine. Removing the middle [::] in the last line gets it though SpecConstr, but the result size is 1501143 and it then runs out of memory in the simplifier.

Building with -dph-par runs fine.

This is probably also why the dph-words benchmark in the testsuite is failing due to using too much memory during compilation.

[rl]

Don't be so impatient! It does terminate eventually after generating 6162 specialisations.

For the lifted version of the function, we produce a loop with this type:

                $wa_s5Ep [Occ=LoopBreaker]
                  :: Data.Vector.Fusion.Stream.Monadic.SPEC
                     -> GHC.Prim.Int#
                     -> Data.Maybe.Maybe Data.Array.Parallel.Base.Util.Tag
                     -> GHC.Prim.Int#
                     -> Data.Maybe.Maybe Data.Array.Parallel.Base.Util.Tag
                     -> (GHC.Types.Int, GHC.Types.Int, Data.Maybe.Maybe GHC.Types.Int)
                     -> (GHC.Types.Bool,
                         Data.Maybe.Maybe GHC.Types.Int,
                         GHC.Types.Int,
                         ((GHC.Types.Int, Data.Maybe.Maybe GHC.Types.Int, GHC.Types.Int),
                          (GHC.Types.Int,
                           Data.Maybe.Maybe GHC.Types.Int,
                           (GHC.Types.Int, GHC.Types.Int, Data.Maybe.Maybe GHC.Types.Int)),
                          Data.Maybe.Maybe GHC.Types.Int),
                         GHC.Types.Int,
                         (GHC.Types.Bool,
                          Data.Maybe.Maybe GHC.Types.Int,
                          GHC.Types.Int,
                          (GHC.Types.Int, GHC.Types.Int),
                          GHC.Types.Int,
                          ((GHC.Types.Int, Data.Maybe.Maybe GHC.Types.Int, GHC.Types.Int),
                           (GHC.Types.Int,
                            Data.Maybe.Maybe GHC.Types.Int,
                            (GHC.Types.Int, GHC.Types.Int, Data.Maybe.Maybe GHC.Types.Int)),
                           Data.Maybe.Maybe GHC.Types.Int)))
                     -> (GHC.Types.Int,
                         (GHC.Types.Int,
                          Data.Maybe.Maybe Data.Array.Parallel.Base.Util.Tag,
                          (GHC.Types.Int, GHC.Types.Int, Data.Maybe.Maybe GHC.Types.Int)),
                         Data.Maybe.Maybe GHC.Types.Double)
                     -> GHC.Prim.State# s_X3Gj
                     -> (# GHC.Prim.State# s_X3Gj, GHC.Types.Int #)

We basically expect SpecConstr to specialise on every Maybe and Bool which is what it does for all combinations that can actually occur when the program runs.

The real problem is that we simply fuse too much in this example. I suppose we'll just have to give up on fusing lifted concatenation when generating sequential code. We don't do it in the parallel case, anyway, which explains why the examples only fail to compile with -fdph-seq. I'm going to rebrand this as a DPH bug.