Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,398
    • Issues 5,398
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 590
    • Merge requests 590
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #21204
Closed
Open
Issue created Mar 09, 2022 by Sebastian Graf@sgraf812Developer

WorkWrap: Deprecate `-ffun-to-thunk` in favor of full laziness

In #21192 (closed), I dicovered that -ffun-to-thunk is basically useless, because full laziness will float out a thunk anyway. E.g., I tried the following program:

f :: Int -> Int
f x = sum (g x) + sum [0..x] + sum (g (x+2))
  where
    g _ = [0..x]
    {-# NOINLINE g #-}

and even without -ffun-to-thunk, we get

$wf
  = \ ww_s1In ->
      let { lvl_s1J6 = eftInt 0# ww_s1In } in
      let { $wg_s1HW = \ @ p_s1HU (_ :: Void#) -> lvl_s1J6 } in
      ...

So even though we don't make $wg into a thunk, we still float out a thunk out of $wg's constant body. So it appears -ffun-to-thunk doesn't have any effect after all if -ffull-laziness is on. To put it another way:

ftt full laziness do we get a thunk?
on on yes
off on yes
on off yes
off off no

As you can see, -ffun-to-thunk only makes a difference if full laziness is off. Who deactivates full laziness but wants WW to still create thunks by passing -ffun-to-thunk?!

Therefore, I propose that -ffun-to-thunk is always off and the flag deprecated.

The advantages are:

  1. One flag less (to explain)
  2. -ffull-laziness governs whether or not we will float out a thunk
  3. We get to delete the code below

Code below:

      -- If fun_to_thunk is False we always keep at least one value
      --   argument: see Note [Protecting the last value argument]
      -- If it is True, we only need to keep a value argument if
      --   the result type is (or might be) unlifted, in which case
      --   dropping the last arg would mean we wrongly used call-by-value
      needs_a_value_lambda
        = not fun_to_thunk
          || might_be_unlifted

      -- Might the result be lifted?
      --     False => definitely lifted
      --     True  => might be unlifted
      -- We may encounter a representation-polymorphic result, in which case we
      -- conservatively assume that we have laziness that needs
      -- preservation. See #15186.
      might_be_unlifted = case isLiftedType_maybe res_ty of
                            Just lifted -> not lifted
                            Nothing     -> True

Since not fun_to_thunk and thus needs_a_value_lambda will always be true, we can delete all this.

Edited Mar 09, 2022 by Sebastian Graf
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking