Call Arity, oneShot or both
Joachim Breitner
mail at joachim-breitner.de
Tue Oct 28 10:08:52 UTC 2014
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#PreservationofsetOneShotLambdaacrossmoduleboundaries
a sensible design?
Greetings,
Joachim
--
Joachim “nomeata” Breitner
mail at joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nomeata at joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141028/d72eb913/attachment.sig>
More information about the ghc-devs
mailing list