Ticket #5945 (new bug)
|Reported by:||simonpj||Owned by:||simonpj|
|Type of failure:||None/Unknown||Difficulty:||Unknown|
|Test Case:||Blocked By:|
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_B1which 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.