[GHC] #14222: Simple text fusion example results in rather duplicative code

GHC ghc-devs at haskell.org
Wed Sep 13 15:33:35 UTC 2017


#14222: Simple text fusion example results in rather duplicative code
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Replying to [comment:2 nomeata]:
 > Shouldn’t the common block elimination on the CMM level take care of
 that kind of duplication?

 Indeed I would have thought so but that is not what I observe.

 Initially I thought the problem was that the blocks differed in their
 source note ticks (which arise through unfoldings since I'm using the
 DWARF-enabled 8.2.1 binary distribution). I suspect that CBE (and indeed
 perhaps CSE in Core and STG) should learn to deal properly with such
 ticks.

 However, after switching back to a non-DWARF-enabled 8.0.2 build I found
 that I could still easily spot duplicate blocks. For instance, with the
 program above I see six blocks of the form,
 {{{#!asm
 block_c6K1_info:
 _c6K1:
         movq 7(%rbx),%r14
         movq 8(%rbp),%rbx
         addq $16,%rbp
         jmp $wloop_all_s6CQ_info
 }}}
 If these were common'd up then that would also allow for a number of
 additional blocks which are currently distinct to be themselves common'd
 up (assuming our CBE pass runs to a fixed point). All-in-all it looks like
 something is broken in CBE. I've opened #14226 to track this. After this
 is fixed I should also make sure that CBE isn't defeated by the presence
 of source notes.

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


More information about the ghc-tickets mailing list