Opened 9 years ago

Last modified 4 years ago

#4831 new bug

Too many specialisations in SpecConstr

Reported by: simonpj Owned by: rl
Priority: low Milestone:
Component: Data Parallel Haskell Version: 7.0.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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.

Change History (12)

comment:1 Changed 9 years ago by igloo

Milestone: 7.0.3

comment:2 Changed 9 years ago by simonmar

Owner: set to simonpj

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by rl

Component: CompilerData Parallel Haskell
Owner: changed from simonpj to rl
Summary: Infinite loop in SpecConstrToo many specialisations in SpecConstr

comment:5 Changed 8 years ago by igloo

Milestone: 7.2.17.4.1

comment:6 Changed 8 years ago by igloo

Milestone: 7.4.17.6.1
Priority: normallow

comment:7 Changed 7 years ago by igloo

Milestone: 7.6.17.6.2

comment:8 Changed 5 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:9 Changed 5 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:10 Changed 4 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:11 Changed 4 years ago by bgamari

Milestone: 8.0.1

Moving DPH tickets out to _|_ as the project is more or less stagnant.

comment:12 Changed 4 years ago by thomie

Type of failure: None/UnknownRuntime performance bug
Note: See TracTickets for help on using tickets.