#14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata):
So why is this worse than the previous version?
Because if `drop` itself is in an inner loop, something like `map (\n -> drop n xs) [0..1000]`, then we have to allocate a box for the the `I#` to wrap the argument. Previously, `drop` would have a specialization rule, and the calls to `drop` would be replaced by a call to `$sdrop`. _But_: Maybe we should simply not worry: For x2n1, allocation goes up by 80%, but the instruction count stays the same (+0.05%). I guess that the extra `I#` constructor needed to allocate is consumed pretty quickly, and never GC’ed… _But again_: This line of reasoning doesn’t cut it for other benchmarks. For example `treejoin`’s allocation goes up by 27%, and the instruction count by 72%(!). With `-f-no-spec-constr`, there is no difference in either number. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14068#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler