[GHC] #10005: Operations on string literals won't be inlined

[GHC]

#10005: Operations on string literals won't be inlined
-------------------------------------+-------------------------------------
        Reporter:  fread2281         |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.8.4
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 We wanted literal strings to be good producers, so that `map f "wubble"`
 would work without generating and then pattern matching on the
 intermediate string.
 That is why `"foo"` desugars to
 {{{
 build (unpackFoldrCString# "foo"#)
 }}}
 This seems reasonable.

 Now `head` has this rule:
 {{{
 "head/build"    forall (g::forall b.(a->b->b)->b->b) .
                 head (build g) = g (\x _ -> x) badHead
 }}}
 (goal: make `head` a good consumer), and that rule fires on `head "foo"`
 giving the result in comment:1.

 It is a bit stupid, but I don't see an immediate way out.  One alternative
 would be to kill off the `head/build` rule.  After all, most `fold/build`
 rules save an entire traversal of the list whereas this one saves the
 allocation and pattern match on a single cons cell.  So the win is much
 smaller.

 If someone would like to
  * Switch off RULES `head/build` and `head/augment` (in `GHC.List`)
  * See what performance difference, if any, happens in `nofib`
  * Track down any increases

 that would be a splendid thing.

 More radical would be to nuke the entire `unpackFoldrCString` ideaa, so
 that literal strings are not good producers.  But I think that would
 probably be bad.

 Simon

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