#12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've learned a bit about this example. 1. It builds big, deeply-nested coercions. 2. The actual memory exhaustion comes from the pretty printer. Here's a dump from `-ticky` of GHC itself, with the `-ddump-hi` on: {{{ Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 24320676 1066014032 0 4 MEiM $waboveNest{v rb81} (ghc-8.1:Pretty) (fun) 19400250 621778256 0 3 MEM beside{v r16q} (ghc-8.1:Pretty) (fun) 2773145 143762232 0 4 EMiL ghc-8.1:Pretty.$wsep1{v rb7d} (fun) 3466978 117540632 0 2 >L base-4.9.0.0:GHC.Base.map{v 01X} (fun) 4143110 114461032 0 1 M oneLiner{v r16K} (ghc-8.1:Pretty) (fun) 1939310 97813720 0 1 M ghc-8.1:Coercion.coercionKind_go{v rrbv} (fun) 1475028 66514184 0 3 i.M containers-0.5.7.1@containers-0.5.7.1:Data.IntMap.Base.$winsert{v rnBj} (fun) 902398 65925152 0 2 LL ghc-8.1:Util.$wsplitAtList{v rhOj} (fun) }}} So clearly the pretty printer is behaving very badly when given deeply nested things to print. 3. Aside from that, a tremendous amount of time is spent in `coercionKind`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12227#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler