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 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. 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. I'll commit shortly and you can look Simon | -----Original Message----- | From: Johan Tibell [mailto:johan.tib...@gmail.com] | 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 <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 _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc