High-level Cmm code and stack allocation

[Simon Marlow]

On 07/01/14 22:53, Simon Peyton Jones wrote:
> | Yes, this is technically wrong but luckily works.  I'd very much like
> | to
> | have a better solution, preferably one that doesn't add any extra
> | overhead.
>
> | __decodeFloat_Int is a C function, so it will not touch the Haskell
> | stack.
>
> This all seems terribly fragile to me.  At least it ought to be surrounded with massive comments pointing out how terribly fragile it is, breaking all the rules that we carefully document elsewhere.
>
> Can't we just allocate a Cmm "area"? The address of an area is a perfectly well-defined Cmm value.

It is fragile, yes.  We can't use static memory because it needs to be 
thread-local.  This particular hack has gone through several iterations 
over the years: first we had static memory, which broke when we did the 
parallel runtime, then we had special storage in the Capability, which 
we gave up when GMP was split out into a separate library, because it 
didn't seem right to have magic fields in the Capability for one library.

I'm looking into whether we can do temporary allocation on the heap for 
this instead.

Cheers,
Simon


> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon
> | Marlow
> | Sent: 07 January 2014 16:05
> | To: Herbert Valerio Riedel; ghc-devs at haskell.org
> | Subject: Re: High-level Cmm code and stack allocation
> |
> | On 04/01/2014 23:26, Herbert Valerio Riedel wrote:
> | > Hello,
> | >
> | > According to Note [Syntax of .cmm files],
> | >
> | > | There are two ways to write .cmm code:
> | > |
> | > |  (1) High-level Cmm code delegates the stack handling to GHC, and
> | > |      never explicitly mentions Sp or registers.
> | > |
> | > |  (2) Low-level Cmm manages the stack itself, and must know about
> | > |      calling conventions.
> | > |
> | > | Whether you want high-level or low-level Cmm is indicated by the
> | > | presence of an argument list on a procedure.
> | >
> | > However, while working on integer-gmp I've been noticing in
> | > integer-gmp/cbits/gmp-wrappers.cmm that even though all Cmm
> | procedures
> | > have been converted to high-level Cmm, they still reference the 'Sp'
> | > register, e.g.
> | >
> | >
> | >      #define GMP_TAKE1_RET1(name,mp_fun)       \
> | >      name (W_ ws1, P_ d1)                      \
> | >      {                                         \
> | >        W_ mp_tmp1;                             \
> | >        W_ mp_result1;                          \
> | >                                                \
> | >      again:                                    \
> | >        STK_CHK_GEN_N (2 * SIZEOF_MP_INT);      \
> | >        MAYBE_GC(again);                        \
> | >                                                \
> | >        mp_tmp1    = Sp - 1 * SIZEOF_MP_INT;    \
> | >        mp_result1 = Sp - 2 * SIZEOF_MP_INT;    \
> | >        ...                                     \
> | >
> | >
> | > So is this valid high-level Cmm code? What's the proper way to
> | allocate
> | > Stack (and/or Heap) memory from high-level Cmm code?
> |
> | Yes, this is technically wrong but luckily works.  I'd very much like
> | to
> | have a better solution, preferably one that doesn't add any extra
> | overhead.
> |
> | The problem here is that we need to allocate a couple of temporary
> | words
> | and take their address; that's an unusual thing to do in Cmm, so it
> | only
> | occurs in a few places (mainly interacting with gmp).  Usually if you
> | want some temporary storage you can use local variables or some
> | heap-allocated memory.
> |
> | Cheers,
> | Simon
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://www.haskell.org/mailman/listinfo/ghc-devs
>