[GHC] #10491: Simplifier explosion with Accelerate

[GHC]

#10491: Simplifier explosion with Accelerate
-------------------------------------+-------------------------------------
        Reporter:  robertce          |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:  7.10.2
       Component:  Compiler          |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------
Description changed by robertce:

Old description:

> In [https://github.com/AccelerateHS/accelerate Accelerate] we are
> encountering problems with the simplifier exploding the number of terms,
> which consequently cause huge compile times. This has only happened since
> the release of 7.10.1 and it appears to still be happening in the
> ghc-7.10 branch.
>
> In the attached Slice.hs you can see what is about the worst case
> example. Trying to compile this with `-O2` yields
>
> {{{
> [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs,
> Slice.o )
> ghc: panic! (the 'impossible' happened)
>   (GHC version 7.10.1.20150602 for x86_64-apple-darwin):
>         Simplifier ticks exhausted
>   When trying UnfoldingDone $j_s1FRp
>   To increase the limit, use -fsimpl-tick-factor=N (default 100)
>   If you need to do this, let GHC HQ know, and what factor you needed
>   To see detailed counts use -ddump-simpl-stats
>   Total ticks: 1668604
> }}}
>
> Bumping the tick factor to 150 stops this from happening, but at that
> point the simplifier blows up. See output.txt for the output of `ghc -v`.
> After half an hour we end up with ~4 million terms. At this point ghc
> takes up about 9GB of memory and I have to kill it.
>
> In order to reproduce this, you will need the `accelerate` package and
> all its various dependencies. The one on hackage works fine. I will try
> to come up with a test case that is not so heavy on dependencies, but I
> wanted to ensure this was raised before 7.10.2 is released.

New description:

 In [https://github.com/AccelerateHS/accelerate Accelerate] we are
 encountering problems with the simplifier exploding the number of terms,
 which consequently cause huge compile times. This has only happened since
 the release of 7.10.1 and it appears to still be happening in the ghc-7.10
 branch.

 In the attached Slice.hs you can see what is about the worst case example.
 Trying to compile this with `-O2` yields

 {{{
 [1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs,
 Slice.o )
 ghc: panic! (the 'impossible' happened)
   (GHC version 7.10.1.20150602 for x86_64-apple-darwin):
         Simplifier ticks exhausted
   When trying UnfoldingDone $j_s1FRp
   To increase the limit, use -fsimpl-tick-factor=N (default 100)
   If you need to do this, let GHC HQ know, and what factor you needed
   To see detailed counts use -ddump-simpl-stats
   Total ticks: 1668604
 }}}

 Bumping the tick factor to 150 stops this from happening, but at that
 point the simplifier blows up. See output.txt for the output of `ghc -v`.
 After half an hour we end up with ~4 million terms. At this point ghc
 takes up about 9GB of memory and I have to kill it.

 In order to reproduce this, you will need the `accelerate` package and all
 its various dependencies. It doesn't have to be the latest from github.
 The version on hackage also works with the example I have given. I will
 try to come up with a test case that is not so heavy on dependencies, but
 I wanted to ensure this was raised before 7.10.2 is released.

--

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