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.dehttp://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