2 % (c) The University of Glasgow 2006
3 % (c) The AQUA Project, Glasgow University, 1994-1998
8 Unfoldings (which can travel across module boundaries) are in Core
9 syntax (namely @CoreExpr@s).
11 The type @Unfolding@ sits ``above'' simply-Core-expressions
12 unfoldings, capturing ``higher-level'' things we know about a binding,
13 usually things that the simplifier found out (e.g., ``it's a
14 literal''). In the corner of a @CoreUnfolding@ unfolding, you will
15 find, unsurprisingly, a Core expression.
19 -- The above warning supression flag is a temporary kludge.
20 -- While working on this module you are encouraged to remove it and fix
21 -- any warnings in the module. See
22 -- http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#Warnings
26 Unfolding, UnfoldingGuidance, -- Abstract types
28 noUnfolding, mkTopUnfolding, mkUnfolding, mkCompulsoryUnfolding, seqUnfolding,
29 evaldUnfolding, mkOtherCon, otherCons,
30 unfoldingTemplate, maybeUnfoldingTemplate,
31 isEvaldUnfolding, isValueUnfolding, isCheapUnfolding, isCompulsoryUnfolding,
32 hasUnfolding, hasSomeUnfolding, neverUnfold,
34 couldBeSmallEnoughToInline,
35 certainlyWillInline, smallEnoughToInline,
37 callSiteInline, CallContInfo(..)
41 #include "HsVersions.h"
46 import PprCore () -- Instances
63 %************************************************************************
65 \subsection{Making unfoldings}
67 %************************************************************************
70 mkTopUnfolding expr = mkUnfolding True {- Top level -} expr
72 mkUnfolding top_lvl expr
73 = CoreUnfolding (occurAnalyseExpr expr)
80 -- OK to inline inside a lambda
82 (calcUnfoldingGuidance opt_UF_CreationThreshold expr)
83 -- Sometimes during simplification, there's a large let-bound thing
84 -- which has been substituted, and so is now dead; so 'expr' contains
85 -- two copies of the thing while the occurrence-analysed expression doesn't
86 -- Nevertheless, we don't occ-analyse before computing the size because the
87 -- size computation bales out after a while, whereas occurrence analysis does not.
89 -- This can occasionally mean that the guidance is very pessimistic;
90 -- it gets fixed up next round
92 instance Outputable Unfolding where
93 ppr NoUnfolding = ptext SLIT("No unfolding")
94 ppr (OtherCon cs) = ptext SLIT("OtherCon") <+> ppr cs
95 ppr (CompulsoryUnfolding e) = ptext SLIT("Compulsory") <+> ppr e
96 ppr (CoreUnfolding e top hnf cheap g)
97 = ptext SLIT("Unf") <+> sep [ppr top <+> ppr hnf <+> ppr cheap <+> ppr g,
100 mkCompulsoryUnfolding expr -- Used for things that absolutely must be unfolded
101 = CompulsoryUnfolding (occurAnalyseExpr expr)
105 %************************************************************************
107 \subsection{The UnfoldingGuidance type}
109 %************************************************************************
112 instance Outputable UnfoldingGuidance where
113 ppr UnfoldNever = ptext SLIT("NEVER")
114 ppr (UnfoldIfGoodArgs v cs size discount)
115 = hsep [ ptext SLIT("IF_ARGS"), int v,
116 brackets (hsep (map int cs)),
123 calcUnfoldingGuidance
124 :: Int -- bomb out if size gets bigger than this
125 -> CoreExpr -- expression to look at
127 calcUnfoldingGuidance bOMB_OUT_SIZE expr
128 = case collect_val_bndrs expr of { (inline, val_binders, body) ->
130 n_val_binders = length val_binders
132 max_inline_size = n_val_binders+2
133 -- The idea is that if there is an INLINE pragma (inline is True)
134 -- and there's a big body, we give a size of n_val_binders+2. This
135 -- This is just enough to fail the no-size-increase test in callSiteInline,
136 -- so that INLINE things don't get inlined into entirely boring contexts,
140 case (sizeExpr (iUnbox bOMB_OUT_SIZE) val_binders body) of
143 | not inline -> UnfoldNever
144 -- A big function with an INLINE pragma must
145 -- have an UnfoldIfGoodArgs guidance
146 | otherwise -> UnfoldIfGoodArgs n_val_binders
147 (map (const 0) val_binders)
150 SizeIs size cased_args scrut_discount
153 (map discount_for val_binders)
155 (iBox scrut_discount)
157 boxed_size = iBox size
159 final_size | inline = boxed_size `min` max_inline_size
160 | otherwise = boxed_size
162 -- Sometimes an INLINE thing is smaller than n_val_binders+2.
163 -- A particular case in point is a constructor, which has size 1.
164 -- We want to inline this regardless, hence the `min`
166 discount_for b = foldlBag (\acc (b',n) -> if b==b' then acc+n else acc)
170 collect_val_bndrs e = go False [] e
171 -- We need to be a bit careful about how we collect the
172 -- value binders. In ptic, if we see
173 -- __inline_me (\x y -> e)
174 -- We want to say "2 value binders". Why? So that
175 -- we take account of information given for the arguments
177 go inline rev_vbs (Note InlineMe e) = go True rev_vbs e
178 go inline rev_vbs (Lam b e) | isId b = go inline (b:rev_vbs) e
179 | otherwise = go inline rev_vbs e
180 go inline rev_vbs e = (inline, reverse rev_vbs, e)
184 sizeExpr :: FastInt -- Bomb out if it gets bigger than this
185 -> [Id] -- Arguments; we're interested in which of these
190 sizeExpr bOMB_OUT_SIZE top_args expr
193 size_up (Type t) = sizeZero -- Types cost nothing
194 size_up (Var v) = sizeOne
196 size_up (Note InlineMe body) = sizeOne -- Inline notes make it look very small
197 -- This can be important. If you have an instance decl like this:
198 -- instance Foo a => Foo [a] where
199 -- {-# INLINE op1, op2 #-}
202 -- then we'll get a dfun which is a pair of two INLINE lambdas
204 size_up (Note _ body) = size_up body -- Other notes cost nothing
206 size_up (Cast e _) = size_up e
208 size_up (App fun (Type t)) = size_up fun
209 size_up (App fun arg) = size_up_app fun [arg]
211 size_up (Lit lit) = sizeN (litSize lit)
213 size_up (Lam b e) | isId b = lamScrutDiscount (size_up e `addSizeN` 1)
214 | otherwise = size_up e
216 size_up (Let (NonRec binder rhs) body)
217 = nukeScrutDiscount (size_up rhs) `addSize`
218 size_up body `addSizeN`
219 (if isUnLiftedType (idType binder) then 0 else 1)
220 -- For the allocation
221 -- If the binder has an unlifted type there is no allocation
223 size_up (Let (Rec pairs) body)
224 = nukeScrutDiscount rhs_size `addSize`
225 size_up body `addSizeN`
226 length pairs -- For the allocation
228 rhs_size = foldr (addSize . size_up . snd) sizeZero pairs
230 size_up (Case (Var v) _ _ alts)
231 | v `elem` top_args -- We are scrutinising an argument variable
233 {- I'm nuking this special case; BUT see the comment with case alternatives.
235 (a) It's too eager. We don't want to inline a wrapper into a
236 context with no benefit.
237 E.g. \ x. f (x+x) no point in inlining (+) here!
239 (b) It's ineffective. Once g's wrapper is inlined, its case-expressions
240 aren't scrutinising arguments any more
244 [alt] -> size_up_alt alt `addSize` SizeIs (_ILIT(0)) (unitBag (v, 1)) (_ILIT(0))
245 -- We want to make wrapper-style evaluation look cheap, so that
246 -- when we inline a wrapper it doesn't make call site (much) bigger
247 -- Otherwise we get nasty phase ordering stuff:
250 -- If we inline g's wrapper, f looks big, and doesn't get inlined
251 -- into h; if we inline f first, while it looks small, then g's
252 -- wrapper will get inlined later anyway. To avoid this nasty
253 -- ordering difference, we make (case a of (x,y) -> ...),
254 -- *where a is one of the arguments* look free.
258 alts_size (foldr addSize sizeOne alt_sizes) -- The 1 is for the scrutinee
259 (foldr1 maxSize alt_sizes)
261 -- Good to inline if an arg is scrutinised, because
262 -- that may eliminate allocation in the caller
263 -- And it eliminates the case itself
266 alt_sizes = map size_up_alt alts
268 -- alts_size tries to compute a good discount for
269 -- the case when we are scrutinising an argument variable
270 alts_size (SizeIs tot tot_disc tot_scrut) -- Size of all alternatives
271 (SizeIs max max_disc max_scrut) -- Size of biggest alternative
272 = SizeIs tot (unitBag (v, iBox (_ILIT(1) +# tot -# max)) `unionBags` max_disc) max_scrut
273 -- If the variable is known, we produce a discount that
274 -- will take us back to 'max', the size of rh largest alternative
275 -- The 1+ is a little discount for reduced allocation in the caller
276 alts_size tot_size _ = tot_size
278 size_up (Case e _ _ alts) = nukeScrutDiscount (size_up e) `addSize`
279 foldr (addSize . size_up_alt) sizeZero alts
280 -- We don't charge for the case itself
281 -- It's a strict thing, and the price of the call
282 -- is paid by scrut. Also consider
283 -- case f x of DEFAULT -> e
284 -- This is just ';'! Don't charge for it.
287 size_up_app (App fun arg) args
288 | isTypeArg arg = size_up_app fun args
289 | otherwise = size_up_app fun (arg:args)
290 size_up_app fun args = foldr (addSize . nukeScrutDiscount . size_up)
291 (size_up_fun fun args)
294 -- A function application with at least one value argument
295 -- so if the function is an argument give it an arg-discount
297 -- Also behave specially if the function is a build
299 -- Also if the function is a constant Id (constr or primop)
300 -- compute discounts specially
301 size_up_fun (Var fun) args
302 | fun `hasKey` buildIdKey = buildSize
303 | fun `hasKey` augmentIdKey = augmentSize
305 = case globalIdDetails fun of
306 DataConWorkId dc -> conSizeN dc (valArgCount args)
308 FCallId fc -> sizeN opt_UF_DearOp
309 PrimOpId op -> primOpSize op (valArgCount args)
310 -- foldr addSize (primOpSize op) (map arg_discount args)
311 -- At one time I tried giving an arg-discount if a primop
312 -- is applied to one of the function's arguments, but it's
313 -- not good. At the moment, any unlifted-type arg gets a
314 -- 'True' for 'yes I'm evald', so we collect the discount even
315 -- if we know nothing about it. And just having it in a primop
316 -- doesn't help at all if we don't know something more.
318 other -> fun_discount fun `addSizeN`
319 (1 + length (filter (not . exprIsTrivial) args))
320 -- The 1+ is for the function itself
321 -- Add 1 for each non-trivial arg;
322 -- the allocation cost, as in let(rec)
323 -- Slight hack here: for constructors the args are almost always
324 -- trivial; and for primops they are almost always prim typed
325 -- We should really only count for non-prim-typed args in the
326 -- general case, but that seems too much like hard work
328 size_up_fun other args = size_up other
331 size_up_alt (con, bndrs, rhs) = size_up rhs
332 -- Don't charge for args, so that wrappers look cheap
333 -- (See comments about wrappers with Case)
336 -- We want to record if we're case'ing, or applying, an argument
337 fun_discount v | v `elem` top_args = SizeIs (_ILIT(0)) (unitBag (v, opt_UF_FunAppDiscount)) (_ILIT(0))
338 fun_discount other = sizeZero
341 -- These addSize things have to be here because
342 -- I don't want to give them bOMB_OUT_SIZE as an argument
344 addSizeN TooBig _ = TooBig
345 addSizeN (SizeIs n xs d) m = mkSizeIs bOMB_OUT_SIZE (n +# iUnbox m) xs d
347 addSize TooBig _ = TooBig
348 addSize _ TooBig = TooBig
349 addSize (SizeIs n1 xs d1) (SizeIs n2 ys d2)
350 = mkSizeIs bOMB_OUT_SIZE (n1 +# n2) (xs `unionBags` ys) (d1 +# d2)
353 Code for manipulating sizes
356 data ExprSize = TooBig
357 | SizeIs FastInt -- Size found
358 (Bag (Id,Int)) -- Arguments cased herein, and discount for each such
359 FastInt -- Size to subtract if result is scrutinised
360 -- by a case expression
362 -- subtract the discount before deciding whether to bale out. eg. we
363 -- want to inline a large constructor application into a selector:
364 -- tup = (a_1, ..., a_99)
365 -- x = case tup of ...
367 mkSizeIs max n xs d | (n -# d) ># max = TooBig
368 | otherwise = SizeIs n xs d
370 maxSize TooBig _ = TooBig
371 maxSize _ TooBig = TooBig
372 maxSize s1@(SizeIs n1 _ _) s2@(SizeIs n2 _ _) | n1 ># n2 = s1
375 sizeZero = SizeIs (_ILIT(0)) emptyBag (_ILIT(0))
376 sizeOne = SizeIs (_ILIT(1)) emptyBag (_ILIT(0))
377 sizeN n = SizeIs (iUnbox n) emptyBag (_ILIT(0))
379 | isUnboxedTupleCon dc = SizeIs (_ILIT(0)) emptyBag (iUnbox n +# _ILIT(1))
380 | otherwise = SizeIs (_ILIT(1)) emptyBag (iUnbox n +# _ILIT(1))
381 -- Treat constructors as size 1; we are keen to expose them
382 -- (and we charge separately for their args). We can't treat
383 -- them as size zero, else we find that (iBox x) has size 1,
384 -- which is the same as a lone variable; and hence 'v' will
385 -- always be replaced by (iBox x), where v is bound to iBox x.
387 -- However, unboxed tuples count as size zero
388 -- I found occasions where we had
389 -- f x y z = case op# x y z of { s -> (# s, () #) }
390 -- and f wasn't getting inlined
393 | not (primOpIsDupable op) = sizeN opt_UF_DearOp
394 | not (primOpOutOfLine op) = sizeN (2 - n_args)
395 -- Be very keen to inline simple primops.
396 -- We give a discount of 1 for each arg so that (op# x y z) costs 2.
397 -- We can't make it cost 1, else we'll inline let v = (op# x y z)
398 -- at every use of v, which is excessive.
400 -- A good example is:
401 -- let x = +# p q in C {x}
402 -- Even though x get's an occurrence of 'many', its RHS looks cheap,
403 -- and there's a good chance it'll get inlined back into C's RHS. Urgh!
404 | otherwise = sizeOne
406 buildSize = SizeIs (_ILIT(-2)) emptyBag (_ILIT(4))
407 -- We really want to inline applications of build
408 -- build t (\cn -> e) should cost only the cost of e (because build will be inlined later)
409 -- Indeed, we should add a result_discount becuause build is
410 -- very like a constructor. We don't bother to check that the
411 -- build is saturated (it usually is). The "-2" discounts for the \c n,
412 -- The "4" is rather arbitrary.
414 augmentSize = SizeIs (_ILIT(-2)) emptyBag (_ILIT(4))
415 -- Ditto (augment t (\cn -> e) ys) should cost only the cost of
416 -- e plus ys. The -2 accounts for the \cn
418 nukeScrutDiscount (SizeIs n vs d) = SizeIs n vs (_ILIT(0))
419 nukeScrutDiscount TooBig = TooBig
421 -- When we return a lambda, give a discount if it's used (applied)
422 lamScrutDiscount (SizeIs n vs d) = case opt_UF_FunAppDiscount of { d -> SizeIs n vs (iUnbox d) }
423 lamScrutDiscount TooBig = TooBig
427 %************************************************************************
429 \subsection[considerUnfolding]{Given all the info, do (not) do the unfolding}
431 %************************************************************************
433 We have very limited information about an unfolding expression: (1)~so
434 many type arguments and so many value arguments expected---for our
435 purposes here, we assume we've got those. (2)~A ``size'' or ``cost,''
436 a single integer. (3)~An ``argument info'' vector. For this, what we
437 have at the moment is a Boolean per argument position that says, ``I
438 will look with great favour on an explicit constructor in this
439 position.'' (4)~The ``discount'' to subtract if the expression
440 is being scrutinised.
442 Assuming we have enough type- and value arguments (if not, we give up
443 immediately), then we see if the ``discounted size'' is below some
444 (semi-arbitrary) threshold. It works like this: for every argument
445 position where we're looking for a constructor AND WE HAVE ONE in our
446 hands, we get a (again, semi-arbitrary) discount [proportion to the
447 number of constructors in the type being scrutinized].
449 If we're in the context of a scrutinee ( \tr{(case <expr > of A .. -> ...;.. )})
450 and the expression in question will evaluate to a constructor, we use
451 the computed discount size *for the result only* rather than
452 computing the argument discounts. Since we know the result of
453 the expression is going to be taken apart, discounting its size
454 is more accurate (see @sizeExpr@ above for how this discount size
457 We use this one to avoid exporting inlinings that we ``couldn't possibly
458 use'' on the other side. Can be overridden w/ flaggery.
459 Just the same as smallEnoughToInline, except that it has no actual arguments.
462 couldBeSmallEnoughToInline :: Int -> CoreExpr -> Bool
463 couldBeSmallEnoughToInline threshold rhs = case calcUnfoldingGuidance threshold rhs of
467 certainlyWillInline :: Unfolding -> Bool
468 -- Sees if the unfolding is pretty certain to inline
469 certainlyWillInline (CoreUnfolding _ _ _ is_cheap (UnfoldIfGoodArgs n_vals _ size _))
470 = is_cheap && size - (n_vals +1) <= opt_UF_UseThreshold
471 certainlyWillInline other
474 smallEnoughToInline :: Unfolding -> Bool
475 smallEnoughToInline (CoreUnfolding _ _ _ _ (UnfoldIfGoodArgs _ _ size _))
476 = size <= opt_UF_UseThreshold
477 smallEnoughToInline other
481 %************************************************************************
483 \subsection{callSiteInline}
485 %************************************************************************
487 This is the key function. It decides whether to inline a variable at a call site
489 callSiteInline is used at call sites, so it is a bit more generous.
490 It's a very important function that embodies lots of heuristics.
491 A non-WHNF can be inlined if it doesn't occur inside a lambda,
492 and occurs exactly once or
493 occurs once in each branch of a case and is small
495 If the thing is in WHNF, there's no danger of duplicating work,
496 so we can inline if it occurs once, or is small
498 NOTE: we don't want to inline top-level functions that always diverge.
499 It just makes the code bigger. Tt turns out that the convenient way to prevent
500 them inlining is to give them a NOINLINE pragma, which we do in
501 StrictAnal.addStrictnessInfoToTopId
504 callSiteInline :: DynFlags
505 -> Bool -- True <=> the Id can be inlined
507 -> Bool -- True if there are are no arguments at all (incl type args)
508 -> [Bool] -- One for each value arg; True if it is interesting
509 -> CallContInfo -- True <=> continuation is interesting
510 -> Maybe CoreExpr -- Unfolding, if any
513 data CallContInfo = BoringCont
514 | InterestingCont -- Somewhat interesting
515 | CaseCont -- Very interesting; the argument of a case
516 -- that decomposes its scrutinee
518 instance Outputable CallContInfo where
519 ppr BoringCont = ptext SLIT("BoringCont")
520 ppr InterestingCont = ptext SLIT("InterestingCont")
521 ppr CaseCont = ptext SLIT("CaseCont")
523 callSiteInline dflags active_inline id lone_variable arg_infos cont_info
524 = case idUnfolding id of {
525 NoUnfolding -> Nothing ;
526 OtherCon cs -> Nothing ;
528 CompulsoryUnfolding unf_template -> Just unf_template ;
529 -- CompulsoryUnfolding => there is no top-level binding
530 -- for these things, so we must inline it.
531 -- Only a couple of primop-like things have
532 -- compulsory unfoldings (see MkId.lhs).
533 -- We don't allow them to be inactive
535 CoreUnfolding unf_template is_top is_value is_cheap guidance ->
538 result | yes_or_no = Just unf_template
539 | otherwise = Nothing
541 n_val_args = length arg_infos
543 yes_or_no = active_inline && is_cheap && consider_safe
544 -- We consider even the once-in-one-branch
545 -- occurrences, because they won't all have been
546 -- caught by preInlineUnconditionally. In particular,
547 -- if the occurrence is once inside a lambda, and the
548 -- rhs is cheap but not a manifest lambda, then
549 -- pre-inline will not have inlined it for fear of
550 -- invalidating the occurrence info in the rhs.
553 -- consider_safe decides whether it's a good idea to
554 -- inline something, given that there's no
555 -- work-duplication issue (the caller checks that).
558 UnfoldIfGoodArgs n_vals_wanted arg_discounts size res_discount
559 | enough_args && size <= (n_vals_wanted + 1)
560 -- Inline unconditionally if there no size increase
561 -- Size of call is n_vals_wanted (+1 for the function)
565 -> some_benefit && small_enough
568 enough_args = n_val_args >= n_vals_wanted
570 some_benefit = or arg_infos || really_interesting_cont
571 -- There must be something interesting
572 -- about some argument, or the result
573 -- context, to make it worth inlining
575 really_interesting_cont
576 | n_val_args < n_vals_wanted = False -- Too few args
577 | n_val_args == n_vals_wanted = interesting_saturated_call
578 | otherwise = True -- Extra args
579 -- really_interesting_cont tells if the result of the
580 -- call is in an interesting context.
582 interesting_saturated_call
584 BoringCont -> not is_top && n_vals_wanted > 0 -- Note [Nested functions]
585 CaseCont -> not lone_variable || not is_value -- Note [Lone variables]
586 InterestingCont -> n_vals_wanted > 0
588 small_enough = (size - discount) <= opt_UF_UseThreshold
589 discount = computeDiscount n_vals_wanted arg_discounts
590 res_discount' arg_infos
591 res_discount' = case cont_info of
593 CaseCont -> res_discount
594 InterestingCont -> 4 `min` res_discount
595 -- res_discount can be very large when a function returns
596 -- construtors; but we only want to invoke that large discount
597 -- when there's a case continuation.
598 -- Otherwise we, rather arbitrarily, threshold it. Yuk.
599 -- But we want to aovid inlining large functions that return
600 -- constructors into contexts that are simply "interesting"
603 if dopt Opt_D_dump_inlinings dflags then
604 pprTrace "Considering inlining"
605 (ppr id <+> vcat [text "active:" <+> ppr active_inline,
606 text "arg infos" <+> ppr arg_infos,
607 text "interesting continuation" <+> ppr cont_info,
608 text "is value:" <+> ppr is_value,
609 text "is cheap:" <+> ppr is_cheap,
610 text "guidance" <+> ppr guidance,
611 text "ANSWER =" <+> if yes_or_no then text "YES" else text "NO"])
618 Note [Nested functions]
619 ~~~~~~~~~~~~~~~~~~~~~~~
620 If a function has a nested defn we also record some-benefit, on the
621 grounds that we are often able to eliminate the binding, and hence the
622 allocation, for the function altogether; this is good for join points.
623 But this only makes sense for *functions*; inlining a constructor
624 doesn't help allocation unless the result is scrutinised. UNLESS the
625 constructor occurs just once, albeit possibly in multiple case
626 branches. Then inlining it doesn't increase allocation, but it does
627 increase the chance that the constructor won't be allocated at all in
628 the branches that don't use it.
630 Note [Lone variables]
631 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
632 The "lone-variable" case is important. I spent ages messing about
633 with unsatisfactory varaints, but this is nice. The idea is that if a
634 variable appears all alone
635 as an arg of lazy fn, or rhs Stop
636 as scrutinee of a case Select
637 as arg of a strict fn ArgOf
639 it is bound to a value
640 then we should not inline it (unless there is some other reason,
641 e.g. is is the sole occurrence). That is what is happening at
642 the use of 'lone_variable' in 'interesting_saturated_call'.
644 Why? At least in the case-scrutinee situation, turning
645 let x = (a,b) in case x of y -> ...
647 let x = (a,b) in case (a,b) of y -> ...
649 let x = (a,b) in let y = (a,b) in ...
650 is bad if the binding for x will remain.
652 Another example: I discovered that strings
653 were getting inlined straight back into applications of 'error'
654 because the latter is strict.
656 f = \x -> ...(error s)...
658 Fundamentally such contexts should not encourage inlining because the
659 context can ``see'' the unfolding of the variable (e.g. case or a
660 RULE) so there's no gain. If the thing is bound to a value.
665 foo = _inline_ (\n. [n])
666 bar = _inline_ (foo 20)
667 baz = \n. case bar of { (m:_) -> m + n }
668 Here we really want to inline 'bar' so that we can inline 'foo'
669 and the whole thing unravels as it should obviously do. This is
670 important: in the NDP project, 'bar' generates a closure data
671 structure rather than a list.
673 * Even a type application or coercion isn't a lone variable.
675 case $fMonadST @ RealWorld of { :DMonad a b c -> c }
676 We had better inline that sucker! The case won't see through it.
678 For now, I'm treating treating a variable applied to types
679 in a *lazy* context "lone". The motivating example was
682 There's no advantage in inlining f here, and perhaps
683 a significant disadvantage. Hence some_val_args in the Stop case
686 computeDiscount :: Int -> [Int] -> Int -> [Bool] -> Int
687 computeDiscount n_vals_wanted arg_discounts result_discount arg_infos
688 -- We multiple the raw discounts (args_discount and result_discount)
689 -- ty opt_UnfoldingKeenessFactor because the former have to do with
690 -- *size* whereas the discounts imply that there's some extra
691 -- *efficiency* to be gained (e.g. beta reductions, case reductions)
694 -- we also discount 1 for each argument passed, because these will
695 -- reduce with the lambdas in the function (we count 1 for a lambda
697 = 1 + -- Discount of 1 because the result replaces the call
698 -- so we count 1 for the function itself
699 length (take n_vals_wanted arg_infos) +
700 -- Discount of 1 for each arg supplied, because the
701 -- result replaces the call
702 round (opt_UF_KeenessFactor *
703 fromIntegral (arg_discount + result_discount))
705 arg_discount = sum (zipWith mk_arg_discount arg_discounts arg_infos)
707 mk_arg_discount discount is_evald | is_evald = discount