Bad FP code generated by x86_64 native code generator.

[igloo]

With this module:

main :: IO ()
main = mapM_ print $ map log2 vals

log2 :: Int -> Double
log2 x = logBase 2 (fromIntegral x)

vals :: [Int]
vals = [1, 2, 17]

on amd64/Linux with the HEAD, I'm seeing:

$ ghc -fforce-recomp -O -fregs-graph -o num012 num012.hs; ./num012
0.0
1.2607434391239006e13
5.153241959769104e13

Ben, are you able to take a look please?

[benl]

This is actually a bug in the x86_64 native code generator:

Compiling libraries/base/GHC/Float.lhs..

-ddump-opt-cmm

GHC.Float.$wlogBase_entry()
    ...
    (_s4aK::F64,) = foreign "ccall"
                    MO_F64_Log((_c74u::F64,))[_unsafe_call_];
    D1 = %MO_F_Quot_W64(_s4aJ::F64, _s4aK::F64);
    jump I64[Sp] ();

-ddump-asm-liveness

GHC.Float.$wlogBase_entry()
    ...
    call log
    ...
    movss %xmm0,%vD_s4aK
        # born:    %vD_s4aK
        # r_dying: %r16

    movsd %vD_s4aJ,%xmm5
        # r_dying: %vD_s4aJ

    divsd %vD_s4aK,%xmm5
        # r_dying: %vD_s4aK

    jmp *(%rbp)

The result of the divsd instruction, %vD_s4aK hasn't been assigned anywhere particular. The linear allocator happens to put it in %xmm0, so it works. The graph allocator happens to put it in %xmm7, so it doesn't.

[benl]

Scratch that, I'm reading the instrs the wrong way around :P. It'll be because it's using movss instead of movsd. Patch pending.

[benl]

Fri Apr 24 16:50:53 EST 2009 Ben.Lippmeier@…

• Fix #3182: 64 bit FP value returned by C calls was getting trashed

movss instruction was being used to move the result into the destination register instead of movsd