Ticket #5945 (new bug)

Opened 15 months ago

Last modified 8 months ago

Lambda lifting

Reported by: simonpj Owned by: simonpj
Priority: normal Milestone: 7.8.1
Component: Compiler Version: 7.4.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

Dan Rosen asks whether GHC has a lambda lifter. Yes, it does: GHC's full-laziness pass also doubles as a lambda lifter

  • It's controlled by the floatOutLambdas field of CoreMonad.FloatOutSwitches
  • This in turn is set from the floatLamArgs field of DynFlags in SimplCore
  • The DynFlags are set in module DynFlags (see -ffloat-all-lams, -ffloat-lam-args)

However on trying a small experiment on

	f x = map (\y -> (x,y))

I see a bug and an infelicity.

  • Bug: the comment with the floatOutLambdas field definition claims that Nothing means float all lambdas to the top. But the code in SetLevels.destLevel treats (Just 0) and Nothing identically, which contradicts the comment. Workaround: use (Just 100)
  • Infelicity: with -ffloat-lam-args=100 we get
    lvl_sdQ =
      \ (@ t_acm) (@ t_acn) (x_a9H :: t_acm) (y_a9I :: t_acn) ->
        (x_a9H, y_a9I)
    
    Foo.f =
      \ (@ t_acm)
        (@ t_acn)
        (x_a9H [Dmd=Just L] :: t_acm)
        (eta_B1 :: [t_acn]) ->
        GHC.Base.map
          @ t_acn @ (t_acm, t_acn) (lvl_sdQ @ t_acm @ t_acn x_a9H) eta_B1
    
    which is good, but then the next simplifier run inlines it straight back in again, via SimplUtils.preInlineUnconditionally.

I think preInlineUnconditionally should be a bit less gung-ho, perhaps, but I don't want to change it until I've see if there are any performance regressions.

Change History

Changed 8 months ago by igloo

  • owner set to simonpj
  • milestone set to 7.8.1
Note: See TracTickets for help on using tickets.