[Git][ghc/ghc][wip/T22241] Deleted 1 commit: Tweaks to postIU

[Sebastian Graf (@sgraf812)]

Sebastian Graf pushed to branch wip/T22241 at Glasgow Haskell Compiler / GHC


WARNING: The push did not contain any new commits, but force pushed to delete the commits and changes below.


Deleted commits:
fba8a684 by Sebastian Graf at 2022-10-14T17:28:24+02:00
Tweaks to postIU

- - - - -


1 changed file:

- compiler/GHC/Core/Opt/Simplify/Utils.hs


Changes:

=====================================
compiler/GHC/Core/Opt/Simplify/Utils.hs
=====================================
@@ -1454,44 +1454,43 @@ postInlineUnconditionally env bind_cxt bndr occ_info rhs
   | exprIsTrivial rhs           = True
   | BC_Join {} <- bind_cxt              -- See point (1) of Note [Duplicating join points]
   , not (phase == FinalPhase)   = False -- in Simplify.hs
-  | otherwise
-  = case occ_info of
-      OneOcc { occ_in_lam = in_lam, occ_int_cxt = int_cxt, occ_n_br = n_br }
-        -- See Note [Inline small things to avoid creating a thunk]
-
-        -> n_br < 100  -- See Note [Suppress exponential blowup]
+  | IAmDead <- occ_info         = True  -- This happens; for example, the case_bndr during case of
+                                        -- known constructor:  case (a,b) of x { (p,q) -> ... }
+                                        -- Here x isn't mentioned in the RHS, so we don't want to
+                                        -- create the (dead) let-binding  let x = (a,b) in ...
+
+  -- See Note [Inline small things to avoid creating a thunk]
+  | OneOcc{occ_in_lam=in_lam, occ_int_cxt=int_cxt, occ_n_br=n_br} <- occ_info
+  , n_br < 100 -- See Note [Suppress exponential blowup]
+  , BC_Let {} <- bind_cxt
+      -- Inlining a join point does not avoid a thunk
+  , smallEnoughToInline uf_opts unfolding
+      -- Small enough to dup
+      -- ToDo: consider discount on smallEnoughToInline if int_cxt is true
+      --
+      -- NB: Do NOT inline arbitrarily big things, even if occ_n_br=1
+      -- Reason: doing so risks exponential behaviour.  We simplify a big
+      --         expression, inline it, and simplify it again.  But if the
+      --         very same thing happens in the big expression, we get
+      --         exponential cost!
+      -- PRINCIPLE: when we've already simplified an expression once,
+      -- make sure that we only inline it if it's reasonably small.
+  , in_lam == NotInsideLam
+      -- Outside a lambda, we want to be reasonably aggressive
+      -- about inlining into multiple branches of case
+      -- e.g. let x = <non-value>
+      --      in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... }
+      -- Inlining can be a big win if C3 is the hot-spot, even if
+      -- the uses in C1, C2 are not 'interesting'
+      -- An example that gets worse if you add int_cxt here is 'clausify'
+  || (isCheapUnfolding unfolding && int_cxt == IsInteresting)
+      -- isCheap => acceptable work duplication; in_lam may be true
+      -- int_cxt to prevent us inlining inside a lambda without some
+      -- good reason.  See the notes on int_cxt in preInlineUnconditionally
+  = True
 
-           && smallEnoughToInline uf_opts unfolding     -- Small enough to dup
-                        -- ToDo: consider discount on smallEnoughToInline if int_cxt is true
-                        --
-                        -- NB: Do NOT inline arbitrarily big things, even if occ_n_br=1
-                        -- Reason: doing so risks exponential behaviour.  We simplify a big
-                        --         expression, inline it, and simplify it again.  But if the
-                        --         very same thing happens in the big expression, we get
-                        --         exponential cost!
-                        -- PRINCIPLE: when we've already simplified an expression once,
-                        -- make sure that we only inline it if it's reasonably small.
-
-           && (in_lam == NotInsideLam ||
-                        -- Outside a lambda, we want to be reasonably aggressive
-                        -- about inlining into multiple branches of case
-                        -- e.g. let x = <non-value>
-                        --      in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... }
-                        -- Inlining can be a big win if C3 is the hot-spot, even if
-                        -- the uses in C1, C2 are not 'interesting'
-                        -- An example that gets worse if you add int_cxt here is 'clausify'
-
-                (isCheapUnfolding unfolding && int_cxt == IsInteresting))
-                        -- isCheap => acceptable work duplication; in_lam may be true
-                        -- int_cxt to prevent us inlining inside a lambda without some
-                        -- good reason.  See the notes on int_cxt in preInlineUnconditionally
-
-      IAmDead -> True   -- This happens; for example, the case_bndr during case of
-                        -- known constructor:  case (a,b) of x { (p,q) -> ... }
-                        -- Here x isn't mentioned in the RHS, so we don't want to
-                        -- create the (dead) let-binding  let x = (a,b) in ...
-
-      _ -> False
+  | otherwise
+  = False
 
 -- Here's an example that we don't handle well:
 --      let f = if b then Left (\x.BIG) else Right (\y.BIG)



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/fba8a684b348cec5565d06c26479b2f6e3a58cd8

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/fba8a684b348cec5565d06c26479b2f6e3a58cd8
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20221014/406f2d33/attachment-0001.html>