RE: Which of the following PrimTyCons have a pointer-sized representations
You can use TyCon.tyConPrimRep, followed by primRepSizeW Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Which of the following PrimTyCons have a pointer-sized representations
On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones simo...@microsoft.com 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). What do you think? Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Which of the following PrimTyCons have a pointer-sized representations
On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones simo...@microsoft.com 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
