Common Context transformation for join points
Joachim Breitner
mail at joachim-breitner.de
Tue Dec 31 11:43:40 UTC 2013
Hi,
Am Dienstag, den 31.12.2013, 11:33 +0000 schrieb Simon Peyton-Jones:
> Interesting. We can discuss when you get back, but let me jot down
> one comment. You write:
>
> | This will always happen if the join point function gets a richer
> | CPR property than the function that it belongs to
>
> Good observation. Maybe we can exploit it directly rather than
> figuring out "common contexts"? If we knew, for each local function,
> whether it was a join point, and if so for what, we could just make
> its inferred CPR property no richer than its "parent", perhaps.
correct, I thought about this as well. It could be a post-processing
step, after demand analysis, but before worker-wrapper, that goes
through the file and reduces CPR information where it is found to be
non-helpful.
There is also a related issue with CPR’ing a function whose call is used
in a argument position:
let f x = ... --
in ... g (f z) ...
When is CPR’ing f useful? Only if g will get w/w’ed in a way that
cancels with the CPR wrapper of f.
And when is that the case? If the demand of g on its first argument is
as least as rich as f CPR’s wrapper. Again, if f’s CPR information is
richer than g’s demand CPR is not useful.
It seems that a generalization of the idea „fix CPR information to be no
richer than useful“ will need some kind of demand information on
arguments.
(In this case, doing CPR of f and then Common Context will clean up any
useless unwrapping, if all uses of f have the same problem.)
Greetings from Karlsruhe,
Joachim
--
Joachim “nomeata” Breitner
mail at joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nomeata at joachim-breitner.de • GPG-Key: 0x4743206C
Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131231/35d4b713/attachment.sig>
More information about the ghc-devs
mailing list