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

On 11/12/12 12:29, Simon Peyton-Jones wrote:
> Johan,
>
> Well, I started to review your patch.  And then I re-discovered how horribly messy that code is; with independent decisions taken in the desugarer, MkId, and TcTyClsDcls, all of which must line up.
>
> So I totally refactored everything which cost me a couple of days (because it has quite wide span).  I'm validating now.
>
> I realise that "unbox-strict-fields" means "unbox it if it's strict", whereas your new "unbox-strict-primitive-fields" is the same but a bit less aggressive:
>     "unbox it if it's strict, AND the unboxed version
>      is at most one word wide"
> Where a Float or Double count as "one word".
>
> So I changed it to "...AND the unboxed version is at most one field wide".  That is we get one field not 2 or 10.  So consider

What is a "field"?

>
> 	data T = MkT !S
>    	data S = MkS Int
>
> then my impl will unbox the S field of MkT because the result is only one field wide, namely an Int.

Wouldn't Johan's have unboxed S too?  (if not, I misunderstood what he did)

> It would be easy to also restrict to *primitive* types, but it seems mildly beneficial not to.
>
> However the flag is then a mis-nomer.

Right, I had been wondering whether "-funbox-strict-small-fields" or 
something would make a better name, since it isn't restricted to 
primitive types.

Cheers,
	Simon



>
> I'll commit shortly and you can look
>
> Simon
>
> | -----Original Message-----
> | From: Johan Tibell [mailto:[email protected]]
> | Sent: 07 December 2012 22:10
> | To: Simon Peyton-Jones
> | Cc: glasgow-haskell-users
> | Subject: Re: Which of the following PrimTyCons have a pointer-sized
> | representations
> |
> | On Fri, Dec 7, 2012 at 10:48 AM, Johan Tibell <[email protected]>
> | wrote:
> | > On Fri, Dec 7, 2012 at 3:36 AM, Simon Peyton-Jones
> | > <[email protected]> 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
>
> _______________________________________________
> Cvs-ghc mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/cvs-ghc
>