Be a little keener to inline

This is really a bug.  A saturated call in an "interesting" context
should inline, but there was a strange "n_val_args > 0" condition, which
was stopping it.  Reported by Roman.

diff --git a/compiler/coreSyn/CoreUnfold.lhs b/compiler/coreSyn/CoreUnfold.lhs
index 9617c59..d8e0cb0 100644 (file)
--- a/compiler/coreSyn/CoreUnfold.lhs
+++ b/compiler/coreSyn/CoreUnfold.lhs
@@ -496,7 +496,7 @@ If the thing is in WHNF, there's no danger of duplicating work,
 so we can inline if it occurs once, or is small
 
 NOTE: we don't want to inline top-level functions that always diverge.
-It just makes the code bigger.  Tt turns out that the convenient way to prevent
+It just makes the code bigger.  It turns out that the convenient way to prevent
 them inlining is to give them a NOINLINE pragma, which we do in 
 StrictAnal.addStrictnessInfoToTopId
 
@@ -562,10 +562,10 @@ callSiteInline dflags active_inline id lone_variable arg_infos cont_info
                  -> True
 
                  | otherwise
-                 -> some_benefit && small_enough
-
+                 -> some_benefit && small_enough 
                  where
                    enough_args = n_val_args >= n_vals_wanted
+                       -- Note [Enough args] 
 
                    some_benefit = or arg_infos || really_interesting_cont
                                -- There must be something interesting
@@ -583,7 +583,7 @@ callSiteInline dflags active_inline id lone_variable arg_infos cont_info
                        = case cont_info of
                            BoringCont -> not is_top && n_vals_wanted > 0       -- Note [Nested functions] 
                            CaseCont   -> not lone_variable || not is_value     -- Note [Lone variables]
-                           InterestingCont -> n_vals_wanted > 0
+                           InterestingCont -> True     -- Something else interesting about continuation
 
                    small_enough = (size - discount) <= opt_UF_UseThreshold
                    discount = computeDiscount n_vals_wanted arg_discounts 
@@ -604,7 +604,8 @@ callSiteInline dflags active_inline id lone_variable arg_infos cont_info
        pprTrace "Considering inlining"
                 (ppr id <+> vcat [text "active:" <+> ppr active_inline,
                                   text "arg infos" <+> ppr arg_infos,
-                                  text "interesting continuation" <+> ppr cont_info,
+                                  text "interesting continuation" <+> ppr cont_info <+> 
+                                       ppr n_val_args,
                                   text "is value:" <+> ppr is_value,
                                   text "is cheap:" <+> ppr is_cheap,
                                   text "guidance" <+> ppr guidance,
@@ -615,6 +616,16 @@ callSiteInline dflags active_inline id lone_variable arg_infos cont_info
     }
 \end{code}
 
+Note [Enough args]
+~~~~~~~~~~~~~~~~~~
+At one stage we considered only inlining a function that has enough
+arguments to saturate its arity.  But we can lose from this. For
+example (f . g) might not be a saturated application of (.), but
+nevertheless f and g might usefully optimise with each other if we
+inlined (.) and f and g.  
+
+Current story (Jan08): inline even if not saturated.
+
 Note [Nested functions]
 ~~~~~~~~~~~~~~~~~~~~~~~
 If a function has a nested defn we also record some-benefit, on the
@@ -628,7 +639,7 @@ increase the chance that the constructor won't be allocated at all in
 the branches that don't use it.
 
 Note [Lone variables]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~
 The "lone-variable" case is important.  I spent ages messing about
 with unsatisfactory varaints, but this is nice.  The idea is that if a
 variable appears all alone