Skip to content

Don't use a generic apply thunk for known calls

Currently, an AP thunk like sat = f a b c will not have its own entry point and info pointer and will instead reuse a generic apply thunk like stg_ap_4_upd.

That's great from a code size perspective, but if f is a known function, a specialised entry point with a plain call can be much faster than figuring out the arity and doing dynamic dispatch.


I prepared a patch over at D5414 that fixes this by checking if the arity of f is unknown (e.g. 0). If not, it will no longer delegate to a generic apply thunk and generate regular entry code and info tables instead.

No impact on allocations, but on counted instructions and code size. Significant changes to counted instructions:

cryptarithm1 -2.5%
lcss -2.3%
paraffins -3.8%
wheel-sieve2 -3.4%
Min -3.8%
Max +0.0%
Geometric Mean -0.2%

And changes to binary size greater than 0.1% (all the other programs, basically):

Program Size Instrs
anna +0.3% -0.2%
expert +0.2% -0.0%
fluid +0.2% -0.1%
grep +0.2% -0.0%
infer +0.2% -0.4%
last-piece +0.2% -0.1%
lift +0.2% -0.0%
paraffins +0.2% -3.8%
prolog +0.2% -0.1%
scs +0.3% -0.0%
transform +0.2% -0.2%
veritas +0.2% +0.0%
Min +0.1% -3.8%
Max +0.3% +0.0%
Geometric Mean +0.1% -0.2%
Trac metadata
Trac field Value
Version 8.6.2
Type Task
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information