[GHC] #10491: Regression, simplifier explosion with Accelerate, cannot compile, increasing tick factor is not a workaround

[George Colpitts]

7.10.1.20150612

It's very sensitive, I see today. Sometimes it fails with

Simplifier ticks exhausted

other times it works. Bizarre

I think the latter is the more common case and I think the former case has
something to do with existing .o file or order of args and -fforce-recomp
may mean it always works but that is very speculative.

The two casesor

$ time ghc -fno-specialise -O2 Slice.hs
[1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs,
Slice.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1.20150612 for x86_64-apple-darwin):
    Simplifier ticks exhausted
  When trying UnfoldingDone $j_s1FS5
  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

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


real    0m19.714s
user    0m18.264s
sys    0m0.875s

$ time ghc -O2 -fno-specialise Slice.hs
[1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs,
Slice.o )

real    0m3.228s
user    0m3.040s
sys    0m0.155s

On Sat, Jun 20, 2015 at 2:03 PM, GHC <ghc-devs at haskell.org> wrote:

> #10491: Regression, simplifier explosion with Accelerate, cannot compile,
> increasing tick factor is not a workaround
> -------------------------------------+-------------------------------------
>         Reporter:  robertce          |                   Owner:
>             Type:  bug               |                  Status:  new
>         Priority:  highest           |               Milestone:  7.10.2
>        Component:  Compiler          |                 Version:  7.10.1
>       Resolution:                    |                Keywords:
> Operating System:  Unknown/Multiple  |            Architecture:
>  Type of failure:  Compile-time      |  Unknown/Multiple
>   performance bug                    |               Test Case:
>       Blocked By:                    |                Blocking:
>  Related Tickets:                    |  Differential Revisions:
> -------------------------------------+-------------------------------------
>
> Comment (by bgamari):
>
>  George, what GHC version did you test `-fno-specialise` on? While
>  yesterday I was able to confirm that `-fno-specialise` seemed to make no
>  difference on a test machine running what should have been 7.10.1 I am now
>  having trouble replicating this on my laptop. Unfortunately I no longer
>  have access to the test environment on which I tested this yesterday but
>  clearly something was inconsistent.
>
>  I am now seeing on multiple machines that `-fno-specialise` indeed allows
>  things to compile,
>  {{{
>  $ ghc -V
>  The Glorious Glasgow Haskell Compilation System, version 7.10.1
>  $$ time ghc Slice.hs -fforce-recomp -O2 -fno-specialise
>  [1 of 1] Compiling Slice            ( Slice.hs, Slice.o )
>
>  real    0m3.759s
>  user    0m1.688s
>  sys     0m0.044s
>  $ time ghc Slice.hs -fforce-recomp -O2
>  [1 of 1] Compiling Slice            ( Slice.hs, Slice.o )
>  ^C
>
>  real    0m51.103s
>  user    0m44.336s
>  sys     0m0.948s
>  }}}
>
>  I am now looking at whether disabling only cross-module specialisation is
>  enough to eliminate the blow-up.
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10491#comment:27>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150620/d0e63147/attachment.html>