High-level Cmm code and stack allocation

[Simon Peyton Jones]

| > Can't we just allocate a Cmm "area"? The address of an area is a
| perfectly well-defined Cmm value.

What about this idea?

Simon

| -----Original Message-----
| From: Simon Marlow [mailto:marlowsd at gmail.com]
| Sent: 08 January 2014 09:26
| To: Simon Peyton Jones; Herbert Valerio Riedel
| Cc: ghc-devs at haskell.org
| Subject: Re: High-level Cmm code and stack allocation
| 
| 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
| >