[GHC] #13226: Compiler allocation regressions from top-level string literal patch

[GHC]

#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):

 > My big question is why we're allowing these literals to be duplicated in
 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