Hi, Am Montag, den 27.10.2014, 22:36 +0000 schrieb Simon Peyton Jones:
| The biggest loser is calendar, which uses scanl. I am not fully sure | what went wrong here: Either the one-shot annotation on the lambda’s | variable got lost somewhere in the pipeline, or despite it being there, | the normal arity analysis did not use it. | | But there is also a winner, fft2, with -1.5% allocations. Here Call | Arity was not good enough, but oneShot did the jobs.
It's always useful to discover what happens. Why didn't Call Arity do the job?
I’ll see what I can do. But we already know that Call Arity is not complete, chance are high that it is among the known unsolvable cases (e.g. a recursive call in an argument position).
Good work! Keep a wiki page to describe the choices, point to the tickets, etc
I added a proposal page https://ghc.haskell.org/trac/ghc/wiki/OneShot here. I can do the implementation, including the interface changes, but I am not sure that I’ll be able to investigate each core2core transformation for where oneShot flags might be lost. But the good thing is that we can still deploy the whole thing without regressions and make then iteratively make the compiler better in preserving this bit.
| best keep the oneShot annotation in the unfoldings: The isOneShotLambda | flag is currently not stored in the interface. I work around this by | making sure that the oneShot function is never inlined in unfoldings, | but maybe it would be better to serialize the isOneShotLambda flag in | interfaces, which might have other good effects?
Serialising the one-shot lambda info sounds like a good plan to me.
Ok, thanks for guidance. Is https://ghc.haskell.org/trac/ghc/wiki/OneShot#PreservationofsetOneShotLambda... a sensible design? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org