[GHC] #12095: GHC and LLVM don't agree on what to do with byteSwap16#

[GHC]

#12095: GHC and LLVM don't agree on what to do with byteSwap16#
-------------------------------------+-------------------------------------
        Reporter:  thoughtpolice     |                Owner:
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.0.2
       Component:  Compiler (LLVM)   |              Version:  8.0.1
      Resolution:                    |             Keywords:  codegen, llvm
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect result  |  Unknown/Multiple
  at runtime                         |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by thoughtpolice):

 So you're right, and the answer with a little more detail is outlined in
 this commit in `binary-serialise-cbor`: https://github.com/well-typed
 /binary-serialise-cbor/commit/d419bdeae39e56531a86d8208e059967863cffb5 if
 you want to read the novel about the LLVM view of things.

 But something about this ticket still makes me feel uneasy. In particular,
 is there ever any reason why the `byteSwap#` primitives do not imply such
 narrowing themselves? Are the high bits always undefined even if they were
 set before? Why does it imply that - because it can't be guaranteed on
 every platform? (e.g. on x86 I believe should be able to do a 16-byte swap
 with simply `xchg ah, al` which should not modify the high 16 bits, that's
 legitimate).

 Obviously not every primitive can be safe (if it pokes memory or
 whatever), but I'm strongly in favor of having sensible behavior for
 operators like this which are merely 'bit fiddling' wrapped up in a single
 MachOp, as opposed to leaving them to have 'undefined behavior' like in C
 which is just a cue for clever compilers to torment me more than they need
 to.

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