#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