[GHC] #7647: UNPACK polymorphic fields

[GHC]

#7647: UNPACK polymorphic fields
-------------------------------------+-------------------------------------
              Reporter:  liyang      |            Owner:  simonpj
                  Type:  feature     |           Status:  new
  request                            |        Milestone:  7.10.1
              Priority:  normal      |          Version:  7.6.1
             Component:  Compiler    |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:  3990
  performance bug                    |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 This morning I was thinking about how this might work. Would unpacking be
 restricted only to single-constructor polymorphic types? For instance, if
 I had,

 {{{
 data Poly a = MkP !Bool {-# UNPACK #-} !a | MkP2

 data Mango = MkMango {-# UNPACK #-} !(Poly Int)
 }}}

 Would I want to produce a representation that is the product of all of the
 unpacked variants? e.g..

 {{{
 data MangoRep = MangoRep1 !Bool !a | MangoRep2
 }}}

 Or would we want to simply not unpack multi-constructor types? This seems
 to be how monomorphic types are currently handled, if I understand the
 code correctly.

 Moreover, how would a pattern match against an unpacked polymorphic type
 be lowered? Would we want to re-box `Poly` when pattern matching on
 `Mango`? Alternatively, we could somehow specialize functions on `Poly` to
 take the unboxed representation.

 Thoughts?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7647#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler