#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