[GHC] #8814: 7.8 optimizes attoparsec improperly

[GHC]

#8814: 7.8 optimizes attoparsec improperly
--------------------------------------------+------------------------------
        Reporter:  joelteon                 |            Owner:
            Type:  bug                      |           Status:  new
        Priority:  normal                   |        Milestone:
       Component:  Compiler                 |          Version:  7.8.1-rc1
      Resolution:                           |         Keywords:
Operating System:  MacOS X                  |     Architecture:  x86_64
 Type of failure:  Runtime performance bug  |  (amd64)
       Test Case:                           |       Difficulty:  Unknown
        Blocking:                           |       Blocked By:
                                            |  Related Tickets:
--------------------------------------------+------------------------------

Comment (by simonpj):

 I have not had any time to devote to this.  I tried
 {{{
 ghc -O T8814.hs -ddump-simpl -o T8814
 }}}
 with and without `-fno-full-laziness`.  Indeed I see the perf difference.

 The Core from `-ddump-simpl` looks very different. Inside `Main.$wa`
 you'll see a call to `runSTRep`.  The function to which `runSTRep` is
 applied looks very different.
  * Without full laziness, it consists of a call to `newArray#` followed by
 a couple of `memcpy` calls
  * With full laziness, it has a rather complicated local recursive
 function that allocates a LOT of memory.

 I have no idea why. I think it must be to do with optimisations being done
 by RULES in the text library.  If I add `-ddump-rule-firings` and grep for
 `TEXT` in the rule names, I get
 {{{
 -- With full laziness
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> unfused
 Rule fired: TEXT tail -> unfused
 Rule fired: TEXT tail -> unfused

 -- Without full laziness
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> fused
 Rule fired: TEXT append -> unfused
 Rule fired: TEXT append -> unfused
 Rule fired: TEXT append -> unfused
 Rule fired: TEXT tail -> unfused
 Rule fired: TEXT tail -> unfused
 Rule fired: TEXT append -> unfused
 }}}
 So there is clearly a difference.  Should that difference have such a
 massive performance impact?  Ask the author of the text library!  Why does
 full laziness have the effect?  Well if you have `(\x. map (f x) (map g
 ys))`, say, full laziness may float out the `map g ys` and then the
 map/map fusion won't happen.

 At this point I hope that someone else will take over debugging to find
 out more.

 Simon

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