[GHC] #8472: Primitive string literals prevent optimization

[GHC]

#8472: Primitive string literals prevent optimization
-------------------------------------+-------------------------------------
        Reporter:  akio              |                Owner:  gridaphobe
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.6.3
      Resolution:                    |             Keywords:  newcomer
Operating System:  Linux             |         Architecture:  x86_64
 Type of failure:  Runtime           |  (amd64)
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by gridaphobe):

 @akio sorry about the duplicate work!

 It looks like our patches are very similar, though I introduce a new
 StgRhs constructor rather than your StgTopBinding type. I think your
 approach is a bit better, as I end up having to deal with the
 (im)possibility of let-binding a literal anywhere (it looks like Stg uses
 `case <lit> of <var> { __DEFAULT -> ... }` to bind literals, which makes
 sense given that they can't be lazy).

 Does your patch validate? I just noticed this afternoon that although my
 patch works for the example and parts of nofib, it causes a linker error
 when building ghc-stage2, due to undefined symbols. I'm setting the label
 for the string literal a bit differently from you, so your patch might be
 fine.

 My CoreLint patch is at
 https://github.com/ghc/ghc/compare/master...gridaphobe:T8472#diff-
 9ad7456ebf7fad38de8b24ddceb9bb3c. Do you want to submit your patch + my
 CoreLint pass, that ought to make for a complete patch :)

 (I also notice that both of our patches could use a nice Note explaining
 why we want to bind string literals at the top level, especially since the
 logic is spread across multiple phases of the compiler)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8472#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler