High-level Cmm code and stack allocation

[Simon Marlow]

On 08/01/2014 10:07, Simon Peyton Jones wrote:
> | > Can't we just allocate a Cmm "area"? The address of an area is a
> | perfectly well-defined Cmm value.
>
> What about this idea?

We don't really have a general concept of areas (any more), and areas 
aren't exposed in the concrete Cmm syntax at all.  The current semantics 
is that areas may overlap with each other, so there should only be one 
active area at any point.  I found that this was important to ensure 
that we could generate good code from the stack layout algorithm, 
otherwise it had to make pessimistic assumptions and use too much stack.

You're going to ask me where this is documented, and I think I have to 
admit to slacking off, sorry :-)  We did discuss it at the time, and I 
made copious notes, but I didn't transfer those to the code.  I'll add a 
Note.

Cheers,
Simon


> 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
> | >
>