[GHC] #10005: Operations on string literals won't be inlined
#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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- An example is attached, GHC won't optimize {{{ head "stringliteral" }}} into {{{ 's' }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10005 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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 rwbarton): 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:9.) 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10005#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: Compile-time performance bug => Runtime performance bug Comment: I believe we use the term `compile-time performance bugs` for the performance of ghc itself. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10005#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC