Operations on string literals won't be inlined

An example is attached, GHC won't optimize

head "stringliteral"

into

's'

Trac metadata

Trac field	Value
Version	7.8.4
Type	Bug
TypeOfFailure	CompileTimePerformance
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import compiler perf labels

Attached file test.hs ($1058).

Attached file test.dump-simpl (download).

-ddump-simpl for test.hs

Your definition of head' is wrong of course, but that's not the issue.

I have good news and bad news.

• Your program (with the definition of head' fixed) does optimize properly in HEAD. (I assume due to ticket:9400#comment:87825.) It also optimizes properly without the INLINE pragma.
• However, if you use the real Prelude.head, then rules fire that turn test = head "foo" into

test =
  GHC.CString.unpackFoldrCString#
    @ Char
    "foo"#
    (\ (x_arw :: Char) _ [Occ=Dead] -> x_arw)
    (GHC.List.badHead @ Char)

and that is more or less a dead end.

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 ticket:10005#comment:95557.

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

I believe we use the term compile-time performance bugs for the performance of ghc itself.

Trac metadata

Trac field	Value
TypeOfFailure	CompileTimePerformance → RuntimePerformance

added Pnormal label

removed compiler perf label