My big question is why we're allowing these literals to be duplicated in
#13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): the first place Good question. Can you show a repro case, please? Returning to your first point, the extra binding is reasonable. After all, if we had {{{ x = f "foo#" y = g "foo#" }}} we might expect CSE to share those literals, and floating them to the top does just that. Moreover the final code is the same either way. But if `f` and `g` were identical (say `unpackCString#`) then we'd CSE `x` and `y` anyway. So we could choose not to float string literals unless they escaped a lambda. That would be easy to do if we wanted to try it. (We want to take them out of lambdas to allow the lambda to be inlined without duplicating the string.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13226#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler