bswap/W64 test fails on i386

      W64:                FAIL (7.80s)
        *** Failed! Falsified (after 51 tests and 2 shrinks):
        -(zext[W16→W64](load[W16](0xc::W32)))
        test ( bits32 buffer ) {
          bits64 ret;
          (ret) = prim %bswap64(%neg(%zx64(bits16[buffer + (12 :: bits32)])));
          return (ret);
        }
        
        0xfcfaffffffffffff /= 0xfcfafffffcfaffff
        Use --quickcheck-replay="(SMGen 11301759829851052901 7931391100024291857,50)" to reproduce.
        Use -p '$2!~/llvm/&&/bswap.W64/' to rerun this test only.

This is due to ghc#25601.

mentioned in merge request !27

changed title from bswap/W64 test fails on i386 under LLVM codegen to bswap/W64 test fails on i386 under

changed title from bswap/W64 test fails on i386 under to bswap/W64 test fails on i386 under NCG

changed title from bswap/W64 test fails on i386 under NCG to bswap/W64 test fails on i386

I am seeing this fail under the NCG as well. Specifically, I have this program:

test ( bits32 buffer ) {
  bits64 ret;
  (ret) = prim %bswap64(%neg(%zx64(bits16[buffer + (12 :: bits32)]))); // bad                 
  return (ret);                                                                               
}

{-# LANGUAGE NegativeLiterals #-}
{-# LANGUAGE UnboxedTuples #-}
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE GHCForeignImportPrim #-}
{-# LANGUAGE UnliftedFFITypes #-}
  
import Numeric
import Data.Bits 
import GHC.Prim                                                                               
import GHC.Word
import GHC.Int
import GHC.IO
import GHC.Ptr
import Data.List
import qualified Data.ByteString as BS

foreign import prim "test" c_test :: Addr# -> State# RealWorld -> (# State# RealWorld, Word64# #)

main :: IO ()
main = do
    let bs = BS.pack $ take 100000 [ fromIntegral i | i <- [(1 :: Int) ..] ]
    n <- BS.useAsCString bs $ \(Ptr addr) -> IO $ \s ->
      case c_test addr s of (# s', n #) -> (# s', W64# n #)
    print $ showHex n ""

which produces 0xf3f1fffff3f1ffff; note the repetition of the 32-bit bit pattern.

I suspect that the problem here is register allocation. Specifically, the register liveness pass produces:

test() { //  [R1]                    
        { []                                 
          # entryIds         = [c3]
          # liveVRegsOnEntry = [(c3, {})]
          # liveSlotsOnEntry = []             
        }             
    [NONREC                
        c3:     movl %esi,%vI_c1
                    # born:    %vI_c1 :: II32
                      
                movw 12(%vI_c1),%vI_n0              // n0 = load 16-bit value
                    # born:    %vI_n0 :: II16
                    # r_dying: %vI_c1 :: II32                                                 
                     
                movzwl %vI_n0,%vI_n1                // n1 = zero extended low 32-bits
                    # born:    %vI_n1 :: II16
                    # r_dying: %vI_n0 :: II16
                     
                xorl %vHi_H1,%vHi_H1                // H1 = 0 (high 32-bits)
                    # born:    %vHi_H1 :: II32
                         
                // MO_S_Neg
                movl %vI_n1,%vI_n2                  // n2 = n1
                    # born:    %vI_n2 :: II32
                    # r_dying: %vI_n1 :: II32
                     
                xorl %vHi_H2,%vHi_H2                // H2 = 0
                    # born:    %vHi_H2 :: II32
                     
                negl %vI_n2                         // n2 = - n2, CF = 1 iff n2 != 0 (negated low word)
                           
                sbbl %vHi_H1,%vHi_H2                // H2 = H2 - (H1 + CF) (negated high word)
                    # r_dying: %vHi_H1 :: II32
                    # w_dying: %vHi_H2 :: II32
                      
                // MO_BSwap
                movl %vI_n2,%vHi_H2                 // H2 = n2
                    # born:    %vHi_H2 :: II32
                    # r_dying: %vI_n2 :: II32
                                    
                movl %vHi_H2,%vI_c2                  // c2 = H2
                    # born:    %vI_c2 :: II32
                                        
                bswapl %vHi_H2                       // H2 = byteswap(H2)                                                                                                                                   
                      
                bswapl %vI_c2                        // c2 = byteswap(c2)
                      
                // Store result
                movl %vI_c2,784(%ebx)
                    # r_dying: %vI_c2 :: II32
                      
                movl %vHi_H2,788(%ebx)
                    # r_dying: %vHi_H2 :: II32
                      
                jmp *(%ebp)
                     ]
}

and the assembler we get is:

test:                              
.Lc3:                               
        movl %esi,%eax                         
        movw 12(%eax),%ax               
        movzwl %ax,%eax            
        xorl %ecx,%ecx                       
        xorl %edx,%edx                         
        negl %eax                       
        sbbl %ecx,%edx                                                                                                                                                                      
        movl %eax,%ecx                      # <------ (1)   
        bswapl %eax                                                                           
        bswapl %ecx        
        movl %ecx,784(%ebx)
        movl %eax,788(%ebx)         
        jmp *(%ebp)                           
        .size test, .-test                    

Note at point (1) we are clobbering H2 (which contains the negated high word) prior to byteswapping. The culpable movl is generated by the GHC.CmmToAsm.X86.CodeGen.genByteSwap, although it is writing to the destination of the byteswap operation as one would expect.

The problem appears to be that both MO_S_Neg and MO_BSwap are treating H2 as (part of) their destination. It appears that H2 came into being as a result of a getNewReg64 in Neg. Consequently, it's rather perplexing that genByteSwap seemingly considers H2 to be both part of its source and destination.