#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