Re: Which of the following PrimTyCons have a pointer-sized representations

On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell wrote:

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