[GHC] #1349: Generalise the ! and UNPACK mechanism for data types, to unpack function arguments

[GHC]

#1349: Generalise the ! and UNPACK mechanism for data types, to unpack function
arguments
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:              
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:  6.12.3      
   Component:  Compiler          |      Version:  6.6.1       
    Keywords:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Testcase:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Old description:

> See this thread:
>    http://www.nabble.com/More-speed-please!-t3411977.html
>
> Briefly the idea is to allow
> {{{
>   data T = MkT (!Int -> Bool)
> }}}
> to make a `MkT` hold strict functions only.  Anyone unpacking a `MkT` can
> assume the function is strict; and anyone building a `MkT` gets a
> strictnes wrapper aound whatever function they supply, so even if they
> supply a lazy function, it's made strict.
>
> Seems like a natural generalisation of the existing strictness and UNPACK
> mechanism for data types.
>
> Lots of details in the thread above.
>
> Simon

New description:

 See this thread:
    http://www.nabble.com/More-speed-please!-t3411977.html

 Briefly the idea is to allow
 {{{
   data T = MkT (!Int -> Bool)
 }}}
 to make a `MkT` hold strict functions only.  Anyone unpacking a `MkT` can
 assume the function is strict; and anyone building a `MkT` gets a
 strictness wrapper aound whatever function they supply, so even if they
 supply a lazy function, it's made strict.

 Seems like a natural generalisation of the existing strictness and UNPACK
 mechanism for data types.

 Lots of details in the thread above.

 Simon

--

Comment(by simonpj):

 Now I'm unsure what to do.  Maybe the rero instructions you give above
 have been overtaken by your change to foldr?  Maybe the extra
 boxing/unboxing that you are nw seeing is the same as in the description
 of the ticket, or maybe not?

 I'm always keen to have well-characterised examples of missed optimisation
 opportunities.  If you think you have one, is it possible for you to
 produce a reproducible standalone test case of the situation as you now
 see it?

 Or maybe its water under the bridge now.

 Thanks

 Simon

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