#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): Let's look at `bound` more closely, {{{#!hs -- |Apply a boundary condition to an index. bound :: sh -> sh -> Boundary a -> Either a sh }}} It takes the size of an array, an index, and a `Boundary a` value describing how lookups falling outside of the array should be handled. The result is either the index that should be looked up or a fixed value. In light of this it seems clear where the deep case analyses appearing in the simplified `$s$fShape:._$cbound_sbQv` are coming from: the compiler is expanding tests for whether each index falls within the array. This test being replicated can be found here https://github.com/AccelerateHS/accelerate/blob/release/0.15/Data/Array/Acce.... Interestingly enough, the `master` branch (5803c5e566a0647139523f2aad06081dc2818ef2) decides not to inline any of the `Data.Array.Accelerate.Array.Sugar.$w$cbound` occurrences, which is why it is able to finish. Interestingly enough the default implementation `Data.Array.Accelerate.Array.Sugar.bound` is not marked as `INLINEABLE` and marking it as `NOINLINE` allows GHC 7.10.2 to compile. Likewise, marking `bound` as `INLINE` on `master` produces a blow-up similar to what we see with 7.10 (actually it does even worse, running out of simplifier ticks even with `-fsimpl-tick-factor=150`). I suppose that GHC 7.10 probably decides on its own that it should be `INLINEABLE` but `master` does not, resulting in the observed difference. 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10491#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler