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

[GHC]

#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):

 Replying to [comment:39 robertce]:
 >
 > It's actually not terribly important that `bound` is inlined for
 Accelerate. We achieve high-performance by generating CUDA C or LLVM IR
 from our DSL rather than having fast Haskell code. The functions in
 `Shape`, like `bound`, are primarily used in our (slow) reference
 interpreter. If necessary, we could just put a `NOINLINE` pragma on
 `bound` or add an `-fno-specialse` to the top of any files affected.

 Adding a `NOINLINE` would be the least intrusive solution. We also will
 have a `-fno-cross-module-specialise` in 7.10.2 which also works around
 the issue but it obviously won't be available in earlier releases.

 > I guess what we really would like is to just not have such an explosion
 when something like `bound` is defined in the way it is. Having GHC figure
 out optimised code for it is not something I see us having any immediate
 need for.

 There are "simple" steps I can imagine we could take to avoid these
 explosions (e.g. stop inlining into an expression after it has reached
 some size) but there are likely Good Reasons (TM) why we don't currently
 do this.

 Simon, perhaps you could comment here?

 > By the way, thanks for looking at this and tracking it down so quickly.
 Sorry I couldn't have been more help.

 No worries! I'm glad I could help.

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