[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 robertce):

 Replying to [comment:38 bgamari]:
 > Regardless, it does seem as though the Accelerate folks would want a
 function like `bound` to be inlined (robertce, perhaps you could comment
 here?). Perhaps the real bug here is our inability to produce a reasonable
 amount of optimized code for this function? That being said, the
 definition of `bound` isn't exactly conducive to efficient implementation.

 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. 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.

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

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