diff options
author | Brian Wignall <brianwignall@gmail.com> | 2020-01-10 10:47:46 -0500 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2020-01-12 21:30:08 -0500 |
commit | 0b5ddc7f2c10ee84631dd6cb5f6368afbc389449 (patch) | |
tree | d9a77d5b2c55d75d9ae5b6fa199612315de9d163 /compiler/specialise/SpecConstr.hs | |
parent | 350e2b78788d47255d27489dfc62d664498b5de4 (diff) | |
download | haskell-0b5ddc7f2c10ee84631dd6cb5f6368afbc389449.tar.gz |
Fix more typos, via an improved Levenshtein-style corrector
Diffstat (limited to 'compiler/specialise/SpecConstr.hs')
-rw-r--r-- | compiler/specialise/SpecConstr.hs | 8 |
1 files changed, 4 insertions, 4 deletions
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) |