Which of the following PrimTyCons have a pointer-sized representations

Johan Tibell johan.tibell at gmail.com
Fri Dec 7 23:10:11 CET 2012

On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones
> <simonpj at 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

More information about the Glasgow-haskell-users mailing list