-
Simon Peyton Jones authored
We were failing to float out a binding that could be floated, because of a confusion in the Lam case of floatExpr. In investigating this I also discoverd that there is really no point at all in giving a different level to variables in a binding group, so I've now given them all the same (in SetLevels.lvlLamBndrs The overall difference is quite minor in a nofib run: Program Size Allocs Runtime Elapsed ------------------------------------------------------------- Min +0.0% -8.5% -28.4% -28.7% Max +0.0% +0.7% -0.7% -1.1% Geometric Mean +0.0% -0.0% -11.6% -11.8% I don't trust those runtimes, but smaller is good! The 8.5% improvement in allocation in fulsom, and seems real. The 0.7% allocation increase only happens in programs with very small allocation. I tracked one down to a call of this form GHC.IO.Handle.Internals.mkDuplexHandle5 = \ args -> GHC.IO.Handle.Internals.openTextEncoding1 mb_codec ha_type (\mb_encoder mb_decoder -> blah) With the new floater the argument of openTextEncoding1 becomes (let lvl = .. in \mb_encoder mb_decoder -> blah) And rightly so. However in fact this argument is a continuation and hence is called once, so the floating is fruitless. Roll on one-shot-function analysis (which I know how to do but fail to get to!).
b284d370