Don't use a generic apply thunk for known calls
authorSebastian Graf <sebastian.graf@kit.edu>
Thu, 6 Dec 2018 15:40:08 +0000 (16:40 +0100)
committerSebastian Graf <sebastian.graf@kit.edu>
Thu, 6 Dec 2018 15:40:08 +0000 (16:40 +0100)
Summary:
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.

This looks at `f`s arity to figure out if it is a known function and if so, it
will not lower it to a generic apply function.

Benchmark results are encouraging: No changes to allocation, but 0.2% less
counted instructions.

Test Plan: Validates locally

Reviewers: simonmar, osa1, simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #16005

Differential Revision: https://phabricator.haskell.org/D5414

compiler/codeGen/StgCmmBind.hs

index 9e14311..d134dfd 100644 (file)
@@ -311,6 +311,7 @@ mkRhsClosure    dflags bndr _cc
                          -- not when profiling: we don't want to
                          -- lose information about this particular
                          -- thunk (e.g. its type) (#949)
+  , idArity fun_id == unknownArity -- don't spoil a known call
 
           -- Ha! an Ap thunk
   = cgRhsStdThunk bndr lf_info payload