High-level Cmm code and stack allocation

Simon Marlow marlowsd at gmail.com
Tue Jan 7 16:06:03 UTC 2014


On 05/01/2014 11:46, Herbert Valerio Riedel wrote:
> On 2014-01-05 at 01:15:53 +0100, Carter Schonwald wrote:
>> hey Herbert,
>> I generally start with looking at the primops.cmm file for examples
>> https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L572-L588
>
>      stg_decodeFloatzuIntzh ( F_ arg )
>      {
>          W_ p, mp_tmp1, W_ mp_tmp_w;
>
>          STK_CHK_GEN_N (WDS(2));
>
>          mp_tmp1  = Sp - WDS(1);
>          mp_tmp_w = Sp - WDS(2);
>
>          ccall __decodeFloat_Int(mp_tmp1 "ptr", mp_tmp_w "ptr", arg);
>
>          return (W_[mp_tmp1], W_[mp_tmp_w]);
>      }
>
> that function in particular is compiled to
>
>      [stg_decodeFloatzuIntzh() //  [F1]
>               { info_tbl: []
>                 stack_info: arg_space: 8 updfr_space: Just 8
>               }
>           {offset
>             cc: _c0::F32 = F1;
>                 goto c4;
>             c4: if ((old + 0) - 2 * 8 < SpLim) goto c6; else goto c7;
>             c6: I64[(young<c5> + 8)] = c5;
>                 call stg_gc_noregs() returns to c5, args: 8, res: 8, upd: 8;
>             c5: goto c4;
>             c7: _c2::I64 = Sp - 1 * 8;
>                 _c3::I64 = Sp - 2 * 8;
>                 _c8::I64 = __decodeFloat_Int;
>                 _c9::I64 = _c2::I64;
>                 _ca::I64 = _c3::I64;
>                 _cb::F32 = _c0::F32;
>                 call "ccall" arg hints:  [PtrHint, PtrHint,]  result hints:  []
>                      (_c8::I64)(_c9::I64, _ca::I64, _cb::F32);
>                 R2 = I64[_c3::I64];
>                 R1 = I64[_c2::I64];
>                 call (P64[(old + 8)])(R2, R1) args: 8, res: 0, upd: 8;
>           }
>       }]
>
> But I see no effort to adjust Sp (i.e. `Sp = Sp - 16`) right before the
> call to __decodeFloat_Int; how is it ensured that __decodeFloat_Int
> doesn't use the locations Sp-8 and Sp-16 for as its local stack?

__decodeFloat_Int is a C function, so it will not touch the Haskell stack.

Cheers,
	Simon


More information about the ghc-devs mailing list