[GHC] #6084: Add stg_ap_pnnv and related call patterns

[GHC]

#6084: Add stg_ap_pnnv and related call patterns
---------------------------------+------------------------------------------
    Reporter:  SimonMeier        |       Owner:  simonmar        
        Type:  feature request   |      Status:  new             
    Priority:  normal            |   Milestone:  7.8.1           
   Component:  Runtime System    |     Version:  7.4.1           
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by SimonMeier):

 Replying to [comment:4 simonmar]:
 > Replying to [comment:3 SimonMeier]:
 >
 > > The change only improves unknown calls with unboxed arguments and a
 final void argument. Attoparsec does not profit, as it does not require
 side-effects. The binary builder could profit, but in its current form it
 would additipnally require the stg_ap_pnnnv and stg_ap_nnnv call patterns.
 >
 > I don't understand why side-effects is an issue, and why you say that
 Attoparsec would not benefit.  Could you elaborate?
 >
 > Also I don't understand why Builder would benefit, because the unknown
 function in this case has type `(Buffer -> IO L.ByteString)`, which is
 just the `stg_ap_pv` pattern, which we already have (it is a higher-order
 function, so the `Buffer` argument won't be unboxed)

 The unboxing has to be done manually using `Addr#` arguments, as shown for
 the new bytestring builder in the original description of this ticket. The
 existing binary builder this would entail the use of functions of type

 {{{
 type BuildStep = ForeignPtr -> Int# -> Int# -> Int# -> IO L.ByteString
 type Builder = BuildStep -> BuildStep
 }}}

 which would actually result in a `stg_ap_ppnnnv` call pattern.

 On a high level, this ticket aims to provide support for unknown calls
 with multiple unboxed arguments and a final void argument. This allows to
 eliminate unnecessary allocations of boxing structures like the `Buffer`
 in the binary builder and `Ptr Word8` in the new bytestring builder. In
 the context of bytestring builders, this elimination is relevant because
 there are cases where we require as much as one unknown function call per
 word written to the output buffer.

 Note that side-effects is not directly an issue. The sequencing of side-
 effects via the final `void` argument is however, as it changes the call
 pattern.

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