Add stg_ap_pnnv and related call patterns
In the implementation of bytestring encoding and decoding libraries, the call patterns stg_ap_pnnv and stg_ap_nnv occur very often. These call patterns are required to avoid boxing the pointers denoting the start and end of the memory area to write to/read from. The first 'p' often stems from using continuation passing style or from a record of configuration paramters. For example, the type of a bytestring builder looks about as follows.
newtype Builder = Builder ((Addr# -> Addr# -> IO BuildSignal) -> Addr# -> Addr# -> IO BuildSignal)
The first Addr# is the pointer to the next free byte and the second Addr# is the pointer to the first byte after the buffer being filled. The current implementation of the bytestring builder in the bytestring-0.10. library however uses
newtype Builder = Builder ((Ptr Word8 -> Ptr Word8 -> IO BuildSignal) -> Ptr Word8 -> Ptr Word8 -> IO BuildSignal)
as the benchmarks demonstrated that the repeated boxing is cheaper than the unknown calls implemented through a series of stg_ap_p, stg_ap_n, stg_ap_n, stg_ap_v calls.
I therefore suggest adding the following call patterns
ppnnv, pnnv, nnv, and nv.
to allow more efficient implementations of bytestring and text decoding/encoding. Note that the 'ppnnv' is used for a constant environment, a continuation, and a range resulting in a side-effecting function.
Trac metadata
Trac field | Value |
---|---|
Version | 7.4.1 |
Type | FeatureRequest |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |