Which of the following PrimTyCons have a pointer-sized representations

Hi, As part of some work I'm doing I need to classify all PrimTyCons by the size of their representation as fields*. I need to classify them into two classes: pointer-sized (or smaller) and larger-than-pointer-sized. I've managed to figure out a bunch of them myself: Pointer-sized: addrPrimTyCon arrayPrimTyCon byteArrayPrimTyCon -- Represented as a pointer to heap object arrayArrayPrimTyCon -- Represented as a pointer to heap object charPrimTyCon doublePrimTyCon -- Only on 64-bit floatPrimTyCon intPrimTyCon int32PrimTyCon int64PrimTyCon -- Only on 64-bit mutableArrayPrimTyCon -- Represented as a pointer to heap object mutableByteArrayPrimTyCon -- Represented as a pointer to heap object mutableArrayArrayPrimTyCon -- Represented as a pointer to heap object wordPrimTyCon word32PrimTyCon word64PrimTyCon -- Only on 64-bit These ones I need help with: bcoPrimTyCon weakPrimTyCon mVarPrimTyCon tVarPrimTyCon mutVarPrimTyCon realWorldTyCon stablePtrPrimTyCon stableNamePrimTyCon statePrimTyCon threadIdPrimTyCon anyTyCon eqPrimTyCon liftedTypeKindTyCon unliftedTypeKindTyCon openTypeKindTyCon constraintKindTyCon superKindTyCon anyKindTyCon I would appreciate any help classifying the bottom half. I will use this to implement -funbox-strict-primitive-fields * For example: while the StgArrWords heap object is a multi-byte object its representation as a field e.g. in data T = C ByteArray# is one pointer (to the StgArrWords heap object). -- Johan

You can use TyCon.tyConPrimRep, followed by primRepSizeW Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Johan Tibell | Sent: 06 December 2012 23:47 | To: glasgow-haskell-users | Subject: Which of the following PrimTyCons have a pointer-sized | representations | | Hi, | | As part of some work I'm doing I need to classify all PrimTyCons by the | size of their representation as fields*. I need to classify them into | two classes: pointer-sized (or smaller) and larger-than-pointer-sized. | I've managed to figure out a bunch of them | | myself: | | Pointer-sized: | | addrPrimTyCon | arrayPrimTyCon | byteArrayPrimTyCon -- Represented as a pointer to heap object | arrayArrayPrimTyCon -- Represented as a pointer to heap object | charPrimTyCon doublePrimTyCon -- Only on 64-bit floatPrimTyCon | intPrimTyCon int32PrimTyCon int64PrimTyCon -- Only on 64-bit | mutableArrayPrimTyCon -- Represented as a pointer to heap object | mutableByteArrayPrimTyCon -- Represented as a pointer to heap object | mutableArrayArrayPrimTyCon -- Represented as a pointer to heap object | wordPrimTyCon word32PrimTyCon word64PrimTyCon -- Only on 64-bit | | These ones I need help with: | | bcoPrimTyCon | weakPrimTyCon | mVarPrimTyCon | tVarPrimTyCon | mutVarPrimTyCon | realWorldTyCon | stablePtrPrimTyCon | stableNamePrimTyCon | statePrimTyCon | threadIdPrimTyCon | anyTyCon | eqPrimTyCon | liftedTypeKindTyCon | unliftedTypeKindTyCon | openTypeKindTyCon | constraintKindTyCon | superKindTyCon | anyKindTyCon | | I would appreciate any help classifying the bottom half. I will use this | to implement -funbox-strict-primitive-fields | | * For example: while the StgArrWords heap object is a multi-byte object | its representation as a field e.g. in data T = C ByteArray# is one | pointer (to the StgArrWords heap object). | | -- Johan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones
You can use TyCon.tyConPrimRep, followed by primRepSizeW
Looking at primRepSizeW I see that the only PrimRep that is bigger than one word is Doubles, Int64s, and Word64s on 32-bit platforms. Manuel (I think wisely) suggested that we should make an exception for these types and unpack them on 32-bit platforms if -funbox-strict-primitive-fields is set, even thought technically they will occupy more space than a pointer. The reasoning is that we want to avoid surprising behavior when users move code between 32-bit and 64-bit platforms, as e.g. unpacking vs not-unpacking Doubles can make a large difference in certain tight loops. But this means that checking the size in can_unbox_prim is no longer necessary, so I could remove that check. This does mean that if we ever add a new PrimTyCon that has a size that's larger than a pointer, the implementation of -funbox-strict-primitive-fields has to change. The alternative would be for me to add primRepSizeForUnboxW :: PrimRep -> Int primRepSizeForUnboxW IntRep = 1 primRepSizeForUnboxW WordRep = 1 primRepSizeForUnboxW Int64Rep = 1 -- [Note: Primitive size exception] primRepSizeForUnboxW Word64Rep= 1 -- [Note: Primitive size exception] primRepSizeForUnboxW FloatRep = 1 -- NB. might not take a full word primRepSizeForUnboxW DoubleRep= 1 -- [Note: Primitive size exception] primRepSizeForUnboxW AddrRep = 1 primRepSizeForUnboxW PtrRep = 1 primRepSizeForUnboxW VoidRep = 0 And use that function in can_unbox_prim. That way we'd get a pattern match warning if we ever add a new PrimRep (and thus need to evaluate if PrimTyCons with that PrimRep should be unpacked by -funbox-strict-primitive-fields). What do you think? Cheers, Johan

On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell
On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones
wrote: You can use TyCon.tyConPrimRep, followed by primRepSizeW
Looking at primRepSizeW I see that the only PrimRep that is bigger than one word is Doubles, Int64s, and Word64s on 32-bit platforms. Manuel (I think wisely) suggested that we should make an exception for these types and unpack them on 32-bit platforms if -funbox-strict-primitive-fields is set, even thought technically they will occupy more space than a pointer. The reasoning is that we want to avoid surprising behavior when users move code between 32-bit and 64-bit platforms, as e.g. unpacking vs not-unpacking Doubles can make a large difference in certain tight loops.
But this means that checking the size in can_unbox_prim is no longer necessary, so I could remove that check. This does mean that if we ever add a new PrimTyCon that has a size that's larger than a pointer, the implementation of -funbox-strict-primitive-fields has to change.
The alternative would be for me to add
primRepSizeForUnboxW :: PrimRep -> Int primRepSizeForUnboxW IntRep = 1 primRepSizeForUnboxW WordRep = 1 primRepSizeForUnboxW Int64Rep = 1 -- [Note: Primitive size exception] primRepSizeForUnboxW Word64Rep= 1 -- [Note: Primitive size exception] primRepSizeForUnboxW FloatRep = 1 -- NB. might not take a full word primRepSizeForUnboxW DoubleRep= 1 -- [Note: Primitive size exception] primRepSizeForUnboxW AddrRep = 1 primRepSizeForUnboxW PtrRep = 1 primRepSizeForUnboxW VoidRep = 0
And use that function in can_unbox_prim. That way we'd get a pattern match warning if we ever add a new PrimRep (and thus need to evaluate if PrimTyCons with that PrimRep should be unpacked by -funbox-strict-primitive-fields).
I went with the latter approach as it seems safer. -- Johan
participants (2)
-
Johan Tibell
-
Simon Peyton-Jones