4221 on new codegen

[Simon Marlow]

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