[GHC] #9013: plusWord2# is buggy

[GHC]

#9013: plusWord2# is buggy
-------------------------------------+------------------------------------
        Reporter:  pumpkin           |            Owner:
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.8.2
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by simonpj):

 The offending code you point to is
 {{{
 pprInstr (ADD size (OpImm (ImmInt (-1))) dst)
   = pprSizeOp (sLit "dec") size dst
 }}}
 Interestingly, this line dates back at least before 2005; see `7d61cb61`
 for example.

 It's surprising to me that
  * it's the ''pretty-printer'' that is doing some peephole-style
 optimisations
  * there is no case for optimising `SUB src 1` to `dec src`, or `SUB src
 (-1)`.

 Moreover, it's clearly too late in the pipeline, because by this point the
 difference between `plusWord#` and `plusWord2#` has disappeared.  So
 fixing the problem by deleting these two lines would lose a perfectly good
 optimisation for `plusWord#`.

 Surely it'd be better for some earlier phase to optimise `(plusWord# x
 (-1))` to `(minusWord# x 1)`; but of course not to do so for `plusWord2#`
 since (as you say) the carry is affected differently.  Moreover, the
 transformation would then be platform-independent, rather than per-
 platform.  Although, now I think about it, the ''reason'' for doing the
 optimisation is to expose the possibility for subsequent, platform-
 specific `inc/dec` optimisations.  Maybe that would be OK if documented.
 Or maybe we could simply do it in passage from Cmm to native code (when we
 know what primop is being used) rather than in the pretty printer?

 It looks to me as if `plusWord2#` is the primop `WordAdd2Op`, which in
 turn is translated to the `CallishMachOp` called `MO_Add2`, which in turn
 is translated (on X86) to `ADC`.  So now I'm confused how the pretty-
 printer's optimisation of `ADD` affected this program.

 Would someone like to dig a little deeper and propose a fix (other than
 the sticking-plaster of deleting above two lines)?

 Simon

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