Describes an interval of evaluation cardinalities. See Note [Evaluation cardinalities] See Note [Bit vector representation for Card]

A subtype of Card for which the upper bound is never 0 (no C_00 or C_10). The only four inhabitants are C_01, C_0N, C_11, C_1N. Membership can be tested with isCardNonAbs. See D and Call for use sites and explanation.

A subtype of Card for which the upper bound is never 1 (no C_01 or C_11). The only four inhabitants are C_00, C_0N, C_10, C_1N. Membership can be tested with isCardNonOnce. See Poly for use sites and explanation.

A demand describes

• How many times a variable is evaluated, via a Cardinality, and
• How deep its value was evaluated in turn, via a SubDemand.

Examples (using Note [Demand notation]):

• seq puts demand 1A on its first argument: It evaluates the argument strictly (1), but not any deeper (A).
• fst puts demand 1P(1L,A) on its argument: It evaluates the argument pair strictly and the first component strictly, but no nested info beyond that (L). Its second argument is not used at all.
• $ puts demand 1C(1,L) on its first argument: It calls (C) the argument function with one argument, exactly once (1). No info on how the result of that call is evaluated (L).
• maybe puts demand MC(M,L) on its second argument: It evaluates the argument function at most once ((M)aybe) and calls it once when it is evaluated.
• fst p + fst p puts demand SP(SL,A) on p: It's 1P(1L,A) multiplied by two, so we get S (used at least once, possibly multiple times).

This data type is quite similar to Scaled SubDemand, but it's scaled by Card, which is an interval on Multiplicity, the upper bound of which could be used to infer uniqueness types. Also we treat AbsDmd and BotDmd specially, as the concept of a SubDemand doesn't apply when there isn't any evaluation at all. If you don't care, simply use (:*).

A sub-demand describes an evaluation context (in the sense of an operational semantics), e.g. how deep the denoted thing is going to be evaluated. See Demand for examples.

See Note [SubDemand denotes at least one evaluation] for a more detailed description of what a sub-demand means.

See Note [Demand notation] for the extensively used short-hand notation. See also Note [Why Boxity in SubDemand and not in Demand?].

A smart constructor for Prod, applying rewrite rules along the semantic equality Prod b [n :* Poly Boxed n, ...] === Poly b n, simplifying to Poly SubDemands when possible. Examples:

• Rewrites P(L,L) (e.g., arguments Boxed, [L,L]) to L
• Rewrites !P(L!L,L!L) (e.g., arguments Unboxed, [L!L,L!L]) to !L
• Does not rewrite P(1L), P(L!L), !P(L) or P(L,A)

viewProd n sd interprets sd as a Prod of arity n, expanding Poly demands as necessary.

Denotes ∪ on Card.

Denotes ∪ on Demand.

Denotes ∩ on Card.

Denotes + on lower and upper bounds of Card.

Denotes + on Demand.

Denotes * on lower and upper bounds of Card.

True = upper bound is 0.

True = upper bound is 1.

True = lower bound is 1.

Is the value used at most once?

Not absent and used strictly. See Note [Strict demands]

Contrast with isStrictUsedDmd. See Note [Strict demands]

Used to suppress pretty-printing of an uninformative demand

We try to avoid tracking weak free variable demands in strictness signatures for analysis performance reasons. See Note [Lazy and unleashable free variables] in GHC.Core.Opt.DmdAnal.

True when the signature indicates all arguments are boxed

First argument of catch#: MC(1,L). Evaluates its arg lazily, but then applies it exactly once to one argument.

Second argument of catch#: MC(1,C(1,L)). Evaluates its arg lazily, but then applies it exactly once to two arguments.

First argument of 'GHC.Exts.maskAsyncExceptions#': 1C(1,L). Called exactly once.

First argument of 'GHC.Exts.atomically#': SC(S,L). Called at least once, possibly many times.

Intersect with [0,1].

Make a Demand evaluated at-most-once.

Make a Demand evaluated at-least-once (e.g. strict).

If the argument is a guaranteed-terminating type (i.e. a non-newtype dictionary) give it strict demand. This is sound because terminating types can't be bottom: See GHC.Core Note [NON-BOTTOM-DICTS invariant] Also split the product type & demand and recur in order to similarly strictify the argument's contained used non-newtype superclass dictionaries. We use the demand as our recursive measure to guarantee termination.

Make a Demand lazy.

Peels one call level from the sub-demand, and also returns how many times we entered the lambda body.

Wraps the SubDemand with a one-shot call demand: d -> C(1,d).

mkCalledOnceDmds n d returns C(1,C1...C(1,d)) where there are n C1's.

Extract the SubDemand of a Demand. PRECONDITION: The SubDemand must be used in a context where the expression denoted by the Demand is under evaluation.

See Note [Computing one-shot info]

See Note [Computing one-shot info]

See Note [Computing one-shot info]

saturatedByOneShots n C(M,C(M,...)) = True = There are at least n nested C(M,..) calls. See Note [Demand on the worker] in GHC.Core.Opt.WorkWrap

Sets Boxity to Unboxed for the Demand, recursing into Prods. Don't recurse into lazy arguments; see GHC.Core.Opt.DmdAnal Note [No lazy, Unboxed demands in demand signature]

Divergence characterises whether something surely diverges. Models a subset lattice of the following exhaustive set of divergence results:

n

nontermination (e.g. loops)

i

throws imprecise exception

p

throws precise exception

c

converges (reduces to WHNF).

The different lattice elements correspond to different subsets, indicated by juxtaposition of indicators (e.g. nc definitely doesn't throw an exception, and may or may not reduce to WHNF).

            Dunno (nipc)
                 |
           ExnOrDiv (nip)
                 |
           Diverges (ni)

As you can see, we don't distinguish n and i. See Note [Precise exceptions and strictness analysis] for why p is so special compared to i.

True if the Divergence indicates that evaluation will not return. See Note [Dead ends].

Captures the result of an evaluation of an expression, by

• Listing how the free variables of that expression have been evaluated (de_fvs)
• Saying whether or not evaluation would surely diverge (de_div)

See Note [Demand env Equality].

Build a potentially terminating DmdEnv from a finite map that says what has been evaluated so far

DmdEnv is a monoid via plusDmdEnv and nopDmdEnv; this is its msum

Characterises how an expression

• Evaluates its free variables (dt_env) including divergence info
• Evaluates its arguments (dt_args)

The demand type of doing nothing (lazy, absent, no Divergence information). Note that it is 'not' the top of the lattice (which would be "may use everything"), so it is (no longer) called topDmdType.

Compute the least upper bound of two DmdTypes elicited /by the same incoming demand/!

When e is evaluated after executing an IO action that may throw a precise exception, we act as if there is an additional control flow path that is taken if e throws a precise exception. The demand type of this control flow path * is lazy and absent (topDmd) and boxed in all free variables and arguments * has exnDiv Divergence result See Note [Precise exceptions and strictness analysis]

So we can simply take a variant of nopDmdType, exnDmdType. Why not nopDmdType? Because then the result of e can never be exnDiv! That means failure to drop dead-ends, see #18086.

The depth of the wrapped DmdType encodes the arity at which it is safe to unleash. Better construct this through mkDmdSigForArity. See Note [Understanding DmdType and DmdSig]

Turns a DmdType computed for the particular Arity into a DmdSig unleashable at that arity. See Note [Understanding DmdType and DmdSig].

True if the signature diverges or throws an imprecise exception in a saturated call. NB: In constrast to isDeadEndSig this returns False for exnDiv. See Note [Dead ends] and Note [Precise vs imprecise exceptions].

True if the signature diverges or throws an exception in a saturated call. See Note [Dead ends].

Returns true if an application to n value args would diverge or throw an exception.

If a function having botDiv is applied to a less number of arguments than its syntactic arity, we cannot say for sure that it is going to diverge. Hence this function conservatively returns False in that case. See Note [Dead ends].

Add extra (topDmd) arguments to a strictness signature. In contrast to etaConvertDmdSig, this prepends additional argument demands. This is used by FloatOut.

We are expanding (x y. e) to (x y z. e z) or reducing from the latter to the former (when the Simplifier identifies a new join points, for example). In contrast to prependArgsDmdSig, this appends extra arg demands if necessary. This works by looking at the DmdType (which was produced under a call demand for the old arity) and trying to transfer as many facts as we can to the call demand of new arity. An arity increase (resulting in a stronger incoming demand) can retain much of the info, while an arity decrease (a weakening of the incoming demand) must fall back to a conservative default.

A demand transformer is a monotone function from an incoming evaluation context (SubDemand) to a DmdType, describing how the denoted thing (i.e. expression, function) uses its arguments and free variables, and whether it diverges.

See Note [Understanding DmdType and DmdSig] and Note [What are demand signatures?].

Extrapolate a demand signature (DmdSig) into a DmdTransformer.

Given a function's DmdSig and a SubDemand for the evaluation context, return how the function evaluates its free variables and arguments.

A special DmdTransformer for data constructors that feeds product demands into the constructor arguments.

A special DmdTransformer for dictionary selectors that feeds the demand on the result into the indicated dictionary component (if saturated). See Note [Demand transformer for a dictionary selector].

Drop all boxity

Remove the demand environment from the signature.

Remove all `C_01 :*` info (but not CM sub-demands) from the demand

Remove all `C_01 :*` info (but not CM sub-demands) from the strictness signature