On 01/02/2011 00:01, Edward Z. Yang wrote:
Current theory:
c1jj:
_s1ep::I32 = I32[(slot<_s1ep::I32> + 4)]; // CmmAssign
_s1fP::I32 = I32[(slot<_s1fP::I32> + 4)]; // CmmAssign
// outOfLine should follow:
_s1eq::F64 = F64[_s1fP::I32 + 3]; // CmmAssign
I32[(young<c1jh> + 4)] = c1jh; // CmmStore
foreign call "ccall" arg hints: [PtrHint,] result hints: []
call_fn_blob(...) returns to c1jh args: ([_s1ep::I32,
_s1eq::F64]) ress: ([_s1ev::F64]) with update
frame 4; // CmmForeignCall
c1jh:
_s1ev::F64 = F64[(slot<_s1ev::F64> + 8)]; // CmmAssign
// emitReturn: Sequel: Assign
_s1ev::F64 = _s1ev::F64; // CmmAssign
F64[(slot<_s1ev::F64> + 8)] = _s1ev::F64; // CmmStore
goto u1Ak; // CmmBranch
Note the line immediately after c1jh, where we reload the ostensibly
spilled _s1ev back into a register. Except that it was never spilled
there in the first place, and we just clobbered the real value. Oops.
Is this interpretation correct?
It sounds plausible, but I really have no idea. The code generator does
not have to generate spill/reloads around foreign calls, the register
allocator will do that.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
