Accelerate examples does not compile with default value of -fsimpl-tick-factor

When doing $ cabal build for: http://github.com/AccelerateHS/accelerate-examples (commit def2495a1e7bd88e444540c3494b8674da99e201):

[31 of 36] Compiling SMVM.Matrix      ( examples/tests/simple/SMVM/Matrix.hs, dist_accelerate/build/accelerate-examples/accelerate-examples-tmp/SMVM/Matrix.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.1 for x86_64-unknown-linux):
	Simplifier ticks exhausted
    When trying UnfoldingDone base:GHC.Base.returnIO1{v r5g} [gid]
    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: 27960

changed weight to 5

added Tbug Trac import labels

changed the description

What -fsimpl-tick-factor makes it work?

Simon

I used -fsimpl-tick-factor=200 and it built.

changed milestone to %7.8.1

changed weight to 7

Trac metadata

Trac field	Value
Priority	normal → high

Does this fail on 7.8.2?

Trac metadata

Trac field	Value
CC	→ george.colpitts@gmail.com

changed milestone to %7.8.4

Moving to 7.8.4.

changed milestone to %7.10.1

Moving (in bulk) to 7.10.4

The file accelerate-examples.cabal in the latest version of that package (0.15.0.0) contains:

if impl(ghc >= 7.6)
   ghc-options:        -fsimpl-tick-factor=130

When I remove those lines, trying to build the package with ghc-7.8.3 still results in a Simplifier ticks exhausted panic.

Steps to reproduce:

$ sudo apt-get install c2hs freeglut3-dev
$ cabal get accelerate-examples==0.15.0.0
$ cd accelerate-examples
$ cabal install --dependencies-only
# `accelerate-cuda` might fail to install, just ignore that
# edit `accelerate-examples.cabal`
$ cabal build

Trac metadata

Trac field	Value
Operating system	Linux → Unknown/Multiple

removed milestone

Moving to 7.12.1

Should the subject/title, "Simplifier ticks exhausted when compiling Accelerate example" be changed since it is no longer accurate? Given that should the priority be changed?

I'm not sure what you mean, George.

As I understand ticket:7521#comment:91936 everything is just fine so long as you don't meddle with the .cabal file. Or is there an actual problem.

Manuel?

Simon

Right, there is no actual problem as long as you don't meddle with the Accelerate .cabal file but the subject/title of this ticket: ""Simplifier ticks exhausted when compiling Accelerate example" suggests there is. I guess a new subject would be something like "Accelerate examples does not compile with default value of -fsimpl-tick-factor" Once we have that title it isn't clear that the priority of this bug should be high, normal or low seems more appropriate to me.

changed title from Simplifier ticks exhausted when compiling Accelerate example. to Accelerate examples does not compile with default value of -fsimpl-tick-factor

See also #8613 (closed), #9070 (closed), #8319, #10459 (closed)

Also #10491 (closed)

changed weight to 5

I'm not even convinced this should be considered to be a bug. Various programs require varying amounts of effort from the simplifier; it is fair to say that accelerate sits on the high end of this spectrum. Do we really want to set the default simplifier tick factor to accommodate this extreme case?

For the moment I'm going to lower the priority of this ticket, although arguably we could just close it.

Trac metadata

Trac field	Value
Priority	high → normal

changed milestone to %8.0.1

Milestone renamed

closed

Replying to [ticket:7521#comment:103365 bgamari]:

this ticket [...] arguably we could just close it.

Yes, -fsimpl-tick-factor=130 is fine.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWorksForMe

added compiler crash label

added Pnormal label