[GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0

[GHC]

#15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0
-------------------------------------+-------------------------------------
        Reporter:  noah              |                Owner:  tdammers
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
                                     |  accelerate,memory,compile
Operating System:  Linux             |         Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  Compile-time      |            Test Case:  accelerate
  performance bug                    |  1.2.0
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by tdammers):

 > But why did it not happen in earlier versions of GHC, which should have
 been equally obedient?

 Do we have evidence of this? So far, I have only tested `accelerate`
 against 8.4 and HEAD, and both show the blow-up. AFAICT, the `accelerate`
 situation is rather specific, I don't see people come up with code like
 this a lot, not with the explicit inlining anyway. Which leaves those
 situations where GHC decides to inline on its own; but for those cases, my
 guess would be that the explanation why this happens now and not before is
 because we simply optimize more aggressively now. I'll run `accelerate`
 and the reproduction case against an older GHC just to double check, but
 I'd expect things to still blow up.

 > Why does accelerate have INLINE pragmas on these nested functions?
 Obedience to those pragmas will certainly cause trouble.

 Well, what do you know, there's already a ticket:
 https://github.com/AccelerateHS/accelerate/issues/428. I took the liberty
 to comment on that, so hopefully we'll get some feedback on the matter
 from there.

 > How can we avoid blow-up when (absent INLINE pragmas) such definition
 nests occur naturally? This is the thing I've been thinking about.

 So essentially this boils down to figuring out whether inlining is going
 to pay off; and the challenge is that just looking at the size before and
 after inlining isn't going to be enough, because normally we expect the
 large post-inlining (or post-case-of-case-transform) core to be large but
 sufficiently shrinkable (by crossing off obvious non-matches). So what we
 would need is a way to tell whether our code, once blown up, will indeed
 be shrinkable, either before we blow it up, or right after (but before any
 further transformations, because those are now potentially expensive).

 This is probably something that should be addressed via #13253 though;
 it's not what causes the problem in this case here.

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