+    See Note [CBV Function Ids: overview] in GHC.Types.Id.Info.

+       -- See Note [CBV Function Ids: overview] in GHC.Types.Id.Info.

+Wrinkles:

+

+(IA1) Conlike is interesting.

+   Consider

+           f d = ...((*) d x y)...

+           ... f (df d')...

+   where df is con-like. Then we'd really like to inline 'f' so that the

+   rule for (*) (df d) can fire.  To do this

+     a) we give a discount for being an argument of a class-op (eg (*) d)

+     b) we say that a con-like argument (eg (df d)) is interesting

+

+(IA2) OtherCon.

+   interestingArg returns

+      (a) NonTrivArg for an arg with an OtherCon [] unfolding

+      (b) ValueArg for an arg with an OtherCon [c1,c2..] unfolding.

+

+   Reason for (a): I found (in the GHC.Internal.Bignum.Integer module) that I was

+   inlining a pretty big function when all we knew was that its arguments

+   were evaluated, nothing more.  That in turn make the enclosing function

+   too big to inline elsewhere.

+

+   Reason for (b): we want to inline integerCompare here

+     integerLt# :: Integer -> Integer -> Bool#

+     integerLt# (IS x) (IS y)                  = x <# y

+     integerLt# x y | LT <- integerCompare x y = 1#

+     integerLt# _ _                            = 0#

+

+(IA3) Rubbish literals.

+   In a worker we might see

+     $wfoo x = let y = RUBBISH in

+               ...(g y True)...

+   where `g` has a wrapper that discards its first argment.  We really really

+   want to inline g's wrapper, to expose that it discards its RUBBISH arg.

+   That may not happen if RUBBISH looks like TrivArg, so we use NonTrivArg

+   instead.  See #26722.  (This reverses the plan in #20035, but the problem

+   reported there appears to have gone away.)

+

+(IA4) Consider a call `f (g x)`. If `f` has a an argument discount on its argument,

+   then f's body scrutinises its argument in a `case` expression, or perhaps applies

+   it.  We give the arg `(g x)` an ArgSummary of `NonTrivArg` so that `f` has a bit

+   of encouragment to inline in these cases.

+

+   Now consider `let y = g x in f y`.  Now we have to look through y's unfolding.

+   When should we do so?  Suppose we did inline `f` so we ended up with

+       let y = g x in ...(case y of alts)...

+   Then we'll call `exprIsConApp_maybe` on `y`; and that looks through "expandable"

+   unfoldings; indeed that's the whole purpose of `exprIsExpanadable`. See

+   Note [exprIsExpandable] in GHC.Core.Utils.

+

+   Conclusion: `interestingArg` should give some encouragement (NonTrivArg) to `f`

+   when the argument is expandable. Hence `uf_expandable` in the `Var` case.

+

+       | isLitRubbish l        = NonTrivArg -- See (IA3) in Note [Interesting arguments]

+                                    -- DFuns are con-like;

+                                    --    see (IA1) in Note [Interesting arguments]

+              -- See (IA2) in Note [Interesting arguments]

+             | uf_expandable cache -> NonTrivArg  -- See (IA4)

+{- *********************************************************************

+********************************************************************* -}

+              spec_id    = setCbvCandidate $

+        | wantCbvForId arg_id

+    work_id  = setCbvCandidate $

+    ~ There is the option of achieving this without eta-expansion if we instead

+      expand the partial application code to check for demands on the calling

+      convention and for it to evaluate the arguments. The main downsides there

+      would be the complexity of the implementation and that it carries a

+      certain overhead even for functions who don't take advantage of this

+      functionality. I haven't tried this approach because it's not trivial to

+      implement and doing W/W splits seems to work well enough.

+

+Currently we use the first approach A) by default, with a flag that allows users

+to fall back to the more aggressive approach B).

+

+I also tried the third approach C) using eta-expansion at call sites to avoid

+modifying the PAP-handling code which wasn't fruitful. See

+https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5614#note_389903.  We could

+still try to do C) in the future by having PAP calls which will evaluate the

+required arguments before calling the partially applied function. But this would

+be neither a small nor simple change so we stick with A) and a flag for B) for

+now.

+

+See also Note [EPT enforcement] and Note [CBV Function Ids: overview]

+The worker `$wf` is a CBV function (see `Note [CBV Function Ids: overview]`

+      , wwUseForUnlifting opts  -- See Note [WW for calling convention]

+

+     NB from Andreas: But I think using an error thunk there would be dodgy no

+     matter what for example if we decide to pass the argument to the bottoming

+     function cbv.  As we might do if the function in question is a worker.  See

+     Note [CBV Function Ids: overview] in GHC.Types.Id.Info. So I just left the

+     strictness check in place on top of threading through the marks from the

+     constructor. It's a *really* cheap and easy check to make anyway.

+import GHC.Core.Utils ( wantCbvForId )

+{- Note [Attaching CBV Marks to ids]

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+See Note [CBV Function Ids: overview] for what is happening here.

+

+During tidy we take the demands on the arguments for any CBV-candidates and

+compute CBV (call-by-value) semantics for each individual argument.  The marks

+themselves then are put onto the function id itself.  This means the code

+generator can get the full calling convention by only looking at the function

+itself without having to inspect the RHS.

+

+The actual logic is in computeCbvInfo and takes:

+  * The function id

+  * The functions rhs

+And gives us back the function annotated with the marks. We call it in:

+  * tidyTopPair for top level bindings

+  * tidyBind for local bindings.

+

+Wrinkles

+

+(ACBV1) Note that we *have* to look at the untidied rhs.  During tidying some

+  knot-tying occurs which can blow up if we look at the post-tidy types of the

+  arguments here.  However we only care if the types are unlifted and that

+  doesn't change during tidy.  so we can just look at the untidied types.

+

+(ACBV2) If the id is boot-exported we don't use a cbv calling convention via

+  marks, as the boot file won't contain them. Which means code calling

+  boot-exported ids might expect these ids to have a vanilla calling convention

+  even if we determine a different one here.

+

+  To be able to avoid this we pass a set of boot exported ids for this module

+  around.  For non top level ids we can skip this. Local ids are never

+  boot-exported as boot files don't have unfoldings. So there this isn't a

+  concern.  See also Note [CBV Function Ids: overview]

+-}

+

+-- See Note [CBV Function Ids: overview]

+  | elemNameSet (idName id) boot_exports

+  = id  -- Can't change calling convention for boot exported things

+        -- See (ACBV2) in Note [Attaching CBV Marks to ids]

+  | otherwise

+  = computeCbvInfo id rhs

+-- See Note [CBV Function Ids: overview]

+-- See Note [CBV Function Ids: overview]

+               removeCbvCandidate fun_id

+      | not $ wantCbvForId arg = NotMarkedCbv

+data ArgSummary

+  = TrivArg       -- Nothing interesting

+  | NonTrivArg    -- Arg has structure

+  | ValueArg      -- Arg is a con-app or PAP

+                  -- ..or con-like. See (IA1) in Note [Interesting arguments]

+                  --                          in GHC.Core.Opt.Simplify.Utils

+-- See (IA1) in Note [Interesting arguments] in GHC.Core.Opt.Simplify.Utils

+        mkStrictFieldSeqs, wantCbvForId,

+Wrinkles

+

+(WF1) Strict constructor fields.  We regard (K x) as work-free even if

+  K is a strict data constructor (see Note [Strict fields in Core])

+      data T a = K !a

+  If we have

+    let t = K x in ...(case t of K y -> blah)...

+  we want to treat t's binding as expandable so that `exprIsConApp_maybe`

+  will look through its unfolding. (NB: exprIsWorkFree implies

+  exprIsExpandable.)

+

+  Note, however, that because K is strict, after inlining we'll get a leftover

+  eval on x, which may or may not disappear

+    let t = K x in ...(case x of y -> blah)...

+  We put up with this extra eval: in effect we count duplicating the eval as

+  work-free.

+

+      DataConWorkId {} -> True  -- Even if the data constructor is strict

+                                -- See (WF1) in Note [exprIsWorkFree]

+NB: exprIsWorkFree implies exprIsExpandable.

+

+If we unbox a constructor with strict fields we want to preserve the information

+that some of the arguments came out of strict fields and therefore should be

+already evaluated and properly tagged (EPT) throughout the body of the

+function.  We express this fact in Core like this:

+              ^^^^ The "extra eval"

+

+Now

+ * Throughout `rhs` the Simplifier can see that `b` is EPT, and can (say)

+   drop evals on `b`.

+ * The EPT enforcement pass will make $wfoo into a CBV function, where

+   the caller guarantees to pass an EPT argument (see Note [EPT enforcement] in

+   GHC.Core.Stg.EnforceEpt)

+ * The code generator will discard that "extra eval" case, because $wfoo is

+   CBV.

+

+See also Note [CBV Function Ids: overview].

+

+In tihs case the argument is known to be properly tagged at the call site so there is

+    -- The EnforceEPT pass has made it a CBV function

+Here we would ordinarily not be strict in y after unboxing.  However if we pass

+it as a regular argument then this means on every iteration of loop we will

+incur an extra seq on y before we can pass it to `myPred` which isn't great!

+That is in STG after tag inference we get:

+But if we add an extra eval on `y` during worker/wrapper we this this:

+Here both x and y are known to be tagged in the function body since we pass

+strict worker args using unlifted cbv.  This means the seqs on x and y both

+become no-ops (via (EPT-codegen) in Not [EPT enforcement]) and, compared to the

+first version, the seq on `y` disappears at runtime.

+

+The downside is that the caller of $wfoo potentially has to evaluate `y` once if

+we can't prove it isn't already evaluated.  The wrapper, which calls `$wfoo` has

+just pulled `y` out of a strict field of a data constructor, so it will always

+be EPT.  See Note [EPT enforcement] for more in this.  This makes GHC itself

+around 1% faster despite doing slightly more work! So this is generally quite

+good.

+

+We only apply this when we think there is a benefit in doing so however. There

+are a number of cases in which it would be useless to insert an extra

+seq. `wantCbvForId` tries to identify these to avoid churn in the

+

+        , wantCbvForId arg_id

+   For zero width types (like Types) there is no benefit as we don't operate on them

+   at runtime at all. This includes things like void#, coercions and state tokens.

+   If the argument is a unlifted type the calling convention already is explicitly

+   cbv. This means inserting a seq on this argument wouldn't do anything as the seq

+   would be a no-op *and* it wouldn't affect the calling convention.

+   If the argument is absent in the body there is no advantage to it being passed as

+   cbv to the function. The function won't ever look at it so we don't save any work.

+   This mostly happens for join points. For example we might have:

+       data T = MkT ![Int] [Char]

+       f t = case t of MkT xs{strict} ys-> snd (xs,ys)

+   and abstract the case alternative to:

+       f t = join j1 = \xs ys -> snd (xs,ys)

+             in case t of MkT xs{strict} ys-> j1 xs xy

+   While we "use" xs inside `j1` it's not used inside the function `snd` we pass it to.

+   In short a absent demand means neither our RHS, nor any function we pass the argument

+   to will inspect it. So there is no work to be saved by forcing `xs` early.

+   NB: There is an edge case where if we rebox we *can* end up seqing an absent value.

+   Note [Absent fillers] has an example of this. However this is so rare it's not worth

+   caring about here.

+   Functions are tricky (see Note [TagInfo of functions] in EnforceEpt).

+   But the gist of it even if we make a higher order function argument strict

+   we can't avoid the tag check when it's used later in the body.

+   So there is no benefit.

+

+Wrinkles:

+

+(WIS1) You might have thought that we can omit the eval if the argument is used

+   strictly demanded in the body.  But you'd be wrong. Consider this code:

+          data T = MkT ![Int]

+          f t = case t of MkT xs{Dmd=STR} -> reverse xs

+

+   The `xs{Dmd=STR}` indicates that `xs` is used strictly by the `reverse xs`.

+   If we do a w/w split, and add the extra eval on `xs`, we'll get

+       $wf xs = case xs of xs1 ->

+                  let t = MkT xs1 in

+                  case t of MkT xs2 -> reverse xs2

+

+   That's not wrong; but you might wonder if the eval on `xs` is needed

+   when it is certainly evaluated by the `reverse`.  But yes, it is (#26722):

+       g s True  t = f s t t

+       g s False t = g s True t

+

+       f True  (MkT xs) t = f False (MkT xs) t

+       f False (MkT xs) _ = xs

+

+   After worker/wrapper we get:

+       g s b t = case t of MkT ww -> $wg s b ww

+       $wg s ds ww = case ds of {

+                      False -> case ww of wg { __DEFAULT -> Bar.$wg s True wg }

+                      True  -> let { t1 = MkT ww } in f s t1 t1 }

+

+   We must make `f` inline inside `$wg`, because `f` too is ww'd, and we

+   don't want to rebox `t1` before passing it to `f`.  BUT while `t1`

+   looks like a HNF, `exprIsHNF` will say False because `MkT` is strict

+   and `ww` isn't evaluated.  So `f` doesn't inline and we get lots of

+   reboxing.

+

+   The Right Thing to to is to add the eval for the data con argument:

+       $wg s ds ww = case ww of ww' { DEFAULT ->

+                     case ds of {

+                      False -> case ww of wg { __DEFAULT -> Bar.$wg s True wg }

+                      True  -> let { t1 = MkT ww' } in f s t1 t1 } }

+

+   Now `t1` will be a HNF, and `f` will inline, and we get

+       $wg s ds ww = case ww of ww' { DEFAULT ->

+                     case ds of {

+                      False -> Bar.$wg s True ww'

+                      True  -> $wf s ww'

+

+  (Ultimately `$wg` will be a CBV function, so that `case ww` will be a

+  no-op: see (EPT-codegen) in Note [EPT enforcement] in GHC.Stg.EnforceEpt.)

+-- as for wantCbvForId so we common up the logic here.

+wantCbvForId :: Var -> Bool

+wantCbvForId v

+  | mark_arity > 0 -- A call-by-value function.

+                   -- See Note [CBV Function Ids: overview]

+(see Note [Evaluated and Properly Tagged]). It establishes the following

+invariant:

+>   * a CBV argument (see Note [CBV Function Ids: overview])

+functions. See Note [CBV Function Ids: overview] for more details.

+(EPT-anal) EPT analysis is implemented in `GHC.Stg.EnforceEpt.inferTags.`

+

+(EPT-rewrite) The EPT rewriter, `GHC.Stg.EnforceEpt.Rewrite.rewriteTopBinds`,

+   establishes the EPT invariant by inserting evals. That is, if

+

+

+  and on CBV arguments as well (Note [CBV Function Ids: overview]).

+

+(EPT-codegen) Finally, code generation for (case x of alts) skips the thunk check

+  when `x` is EPT. This is done (a bit indirectly) thus:

+   * GHC.StgToCmm.Expr.cgCase: builds a `sequel`, and recurses into `cgExpr` on `x`.

+   * When `cgExpr` sees a `x` goes to `cgIdApp`, which uses `getCallMethod`.

+   * Then `getCallMethod` sees that `x` is EPT (via `idTagSigMaybe`), and

+     returns `InferredReturnIt`.

+   * Now `cgIdApp` can jump straight to the case-alternative switch in the `sequel`

+     constructed by `cgCase`.

+

+(EPT-export) We also export the EPTness of top level bindings to allow this optimisation

+

+  constructor or CBV function. Note [CBV Function Ids: overview] has the details.

+    -- See Note [CBV Function Ids: overview].

+  , isTaggedSig sig -- This `id` is evaluated and properly tagged; no need to enter it

+                    -- See (EPT-codegen) in Note [EPT enforcement] in GHC.Stg.EnforceEpt

+

+  -- When profiling we must enter all potential functions to make sure we update

+  -- the SCC even if the function itself is already evaluated.

+

+  = InferedReturnIt -- See (EPT-codegen) in Note [EPT enforcement]

+        -- See (EPT-codegen) in Note [EPT enforcement] in GHC.Stg.EnforceEpt

+        setCbvCandidate, removeCbvCandidate,

+-- See Note [CBV Function Ids: overview]

+asJoinId id arity

+  = warnPprTrace (not (isLocalId id))

+      "global id being marked as join var"  (ppr id) $

+    id `setIdDetails` JoinId arity cbv_info

+   cbv_info = case Var.idDetails id of

+                 VanillaId          -> Nothing

+                 WorkerLikeId marks -> Just marks

+                 JoinId _ mb_marks  -> mb_marks

+                 _ -> pprTraceDebug "asJoinId"

+                         (ppr id <+> pprIdDetails (idDetails id)) $

+                      Nothing

+   -- Can workers become join ids? Yes!

+   -- See Note [CBV Function Ids: overview] in GHC.Types.Id.Info

+                  -- See Note [Which Ids should be CBV candidates?]

+      -- that must be visible to CodeGen. See Note [CBV Function Ids: overview]

+-- | Make this Id into a candidate for CBV treatment, if possible.

+-- See Note [CBV Function Ids: overview] in GHC.Types.Id.Info

+setCbvCandidate :: Id -> Id

+setCbvCandidate id =

+-- | Remove any CBV-candidate info from a given Id.

+-- See Note [CBV Function Ids: overview] in GHC.Types.Id.Info

+removeCbvCandidate :: Id -> Id

+removeCbvCandidate id =

+  let details = case idDetails id of

+        WorkerLikeId{}      -> Just $ VanillaId

+        JoinId arity Just{} -> Just $ JoinId arity Nothing

+        _                   -> Nothing

+  in maybeModifyIdDetails details id

+

+        -- See Note [CBV Function Ids: overview]

+        -- See Note [CBV Function Ids: overview]