Shouldn’t the common block elimination on the CMM level take care of
#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]: 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