Simon Peyton Jones pushed to branch wip/T23109a at Glasgow Haskell Compiler / GHC Commits: 826ffb39 by Simon Peyton Jones at 2025-04-19T00:17:28+01:00 Comments only - - - - - 2 changed files: - compiler/GHC/Core/Opt/SetLevels.hs - testsuite/tests/simplCore/should_run/simplrun009.hs Changes: ===================================== compiler/GHC/Core/Opt/SetLevels.hs ===================================== @@ -701,9 +701,9 @@ lvlMFE env strict_ctxt ann_expr -- See Note [Saving work] is_hnf = exprIsHNF expr - saves_work = escapes_value_lam -- (a) - && not is_hnf -- (b) - && not float_is_new_lam -- (c) + saves_work = escapes_value_lam -- (SW-a) + && not is_hnf -- (SW-b) + && not float_is_new_lam -- (SW-c) escapes_value_lam = dest_lvl `ltMajLvl` (le_ctxt_lvl env) -- See Note [Floating to the top] @@ -728,19 +728,19 @@ Doing so can save an unbounded amount of work. But see also Note [Floating to the top]. So we definitely float an expression out if -(a) It will escape a value lambda (escapes_value_lam) -(b) The expression is not a head-normal form (exprIsHNF); see (SW1, SW2). -(c) Floating does not require wrapping it in value lambdas (float_is_new_lam). +(SW-a) It will escape a value lambda (escapes_value_lam) +(SW-b) The expression is not a head-normal form (exprIsHNF); see (SW1, SW2). +(SW-c) Floating does not require wrapping it in value lambdas (float_is_new_lam). See (SW3) below Wrinkles: -(SW1) Concerning (b) I experimented with using `exprIsCheap` rather than +(SW1) Concerning (SW-b) I experimented with using `exprIsCheap` rather than `exprIsHNF` but the latter seems better, according to nofib (`spectral/mate` got 10% worse with exprIsCheap). It's really a bit of a heuristic. -(SW2) What about omitting (b), and hence floating HNFs as well? The danger of +(SW2) What about omitting (SW-b), and hence floating HNFs as well? The danger of doing so is that we end up floating out a HNF from a cold path (where it might never get allocated at all) and allocating it all the time regardless. Example @@ -759,7 +759,7 @@ Wrinkles: - Occasionally decreases runtime allocation (T12996 -2.5%) - Slightly mixed effect on nofib: (puzzle -10%, mate -5%, cichelli +5%) but geometric mean is -0.09%. - Overall, a win. + Overall, a small win. (SW3) Concerning (c), if we are wrapping the thing in extra value lambdas (in abs_vars), then nothing is saved. E.g. ===================================== testsuite/tests/simplCore/should_run/simplrun009.hs ===================================== @@ -6,7 +6,10 @@ -- It produces a nested unfold that should look something -- like the code below. Note the 'lvl1_shW'. It is BAD -- if this is a lambda instead; you get a lot more allocation --- See Note [Saving allocation] in GHC.Core.Opt.SetLevels +-- +-- LATER (2025): But in the end it seems better NOT to float lambdas, +-- unless they go to top level. +-- See (SW2) in Note [Saving work] in GHC.Core.Opt.SetLevels {- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/826ffb39ca642c1f3ac013485b0b0b6f... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/826ffb39ca642c1f3ac013485b0b0b6f... You're receiving this email because of your account on gitlab.haskell.org.