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

 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/Accelerate/Array/Representation.hs#L110.

 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