diff options
Diffstat (limited to 'compiler/specialise')
| -rw-r--r-- | compiler/specialise/Rules.hs | 4 | ||||
| -rw-r--r-- | compiler/specialise/SpecConstr.hs | 8 |
2 files changed, 6 insertions, 6 deletions
diff --git a/compiler/specialise/Rules.hs b/compiler/specialise/Rules.hs index 1eb1dab812..6e391d3fe2 100644 --- a/compiler/specialise/Rules.hs +++ b/compiler/specialise/Rules.hs @@ -128,7 +128,7 @@ Note [Overall plumbing for rules] (b) from the ModGuts, (c) from the CoreMonad, and (d) from its mutable variable - [Of coures this means that we won't see new EPS rules that come in + [Of course this means that we won't see new EPS rules that come in during a single simplifier iteration, but that probably does not matter.] @@ -317,7 +317,7 @@ ruleIsVisible vis_orphs Rule { ru_orphan = orph, ru_origin = origin } {- Note [Where rules are found] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The rules for an Id come from two places: - (a) the ones it is born with, stored inside the Id iself (idCoreRules fn), + (a) the ones it is born with, stored inside the Id itself (idCoreRules fn), (b) rules added in other modules, stored in the global RuleBase (imp_rules) It's tempting to think that diff --git a/compiler/specialise/SpecConstr.hs b/compiler/specialise/SpecConstr.hs index 9dcf9bb9eb..a5f05cac50 100644 --- a/compiler/specialise/SpecConstr.hs +++ b/compiler/specialise/SpecConstr.hs @@ -791,7 +791,7 @@ After optimisation, including SpecConstr, we get: Not good! We build an (I# x) box every time around the loop. SpecConstr (as described in the paper) does not specialise f, despite -the call (f ... (I# x)) because 'y' is not scrutinied in the body. +the call (f ... (I# x)) because 'y' is not scrutinised in the body. But it is much better to specialise f for the case where the argument is of form (I# x); then we build the box only when returning y, which is on the cold path. @@ -804,7 +804,7 @@ Here 'x' is not scrutinised in f's body; but if we did specialise 'f' then the call (g x) might allow 'g' to be specialised in turn. So sc_keen controls whether or not we take account of whether argument is -scrutinised in the body. True <=> ignore that, and speicalise whenever +scrutinised in the body. True <=> ignore that, and specialise whenever the function is applied to a data constructor. -} @@ -1164,7 +1164,7 @@ instance Outputable ArgOcc where evalScrutOcc :: ArgOcc evalScrutOcc = ScrutOcc emptyUFM --- Experimentally, this vesion of combineOcc makes ScrutOcc "win", so +-- Experimentally, this version of combineOcc makes ScrutOcc "win", so -- that if the thing is scrutinised anywhere then we get to see that -- in the overall result, even if it's also used in a boxed way -- This might be too aggressive; see Note [Reboxing] Alternative 3 @@ -1934,7 +1934,7 @@ where, say, co :: Foo ~R (Int,Int) Here we definitely do want to specialise for that pair! We do not -match on the structre of the coercion; instead we just match on a +match on the structure of the coercion; instead we just match on a coercion variable, so the RULE looks like forall (x::Int, y::Int, co :: (Int,Int) ~R Foo) |