Don't use a generic apply thunk for known calls

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

1 files changed, 1 insertions, 0 deletions

diff --git a/compiler/codeGen/StgCmmBind.hs b/compiler/codeGen/StgCmmBind.hs
index 9e14311d42..d134dfd677 100644
--- a/compiler/codeGen/StgCmmBind.hs
+++ b/compiler/codeGen/StgCmmBind.hs
@@ -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