Re: Common subexpression elemination (CSE)

On 11/28/06, Mark T.B. Carroll wrote:
"Dinko Tenev"
writes: (snip) How exactly can CSE cause space leaks, and what does this have to do with strictness?
I puzzled over Lennart's comment too, and the theory I formed was that you might have the same expression used in different parts of a function, where the compiler hasn't realised that the remaining reference to the expression is in a part of the function that isn't going to be executed this time, so it is holding on to the expression's value even though it is never going to be used. (For instance, with a recursive function, all the previous calls may be holding on to their version of the value until the call stack has come back out past them again.)
-- Mark
I see this as a special case of Lennart's point -- you're talking about references that are practically dead (just not burried yet :) The compiler should probably be able to kill these early by a CPS transform, shouldn't it? -- Cheers, Dinko

Hello Dinko, Wednesday, November 29, 2006, 11:56:49 AM, you wrote:
How exactly can CSE cause space leaks, and what does this have to do with strictness?
standard example is x = [1..9] ++ [1..9] comparing to x = a++a where a=[1..9] first version runs (without CSE transformation) in fixed space, but computes [1..9] twice. second version computes its only once but needs more memory to hold results for second consumption. so, it's a classical space/time trade-off and lack of CSE transformation in such circumstances allow program to explicitly select whether he need better speed or space usage in the absence of laziness, entire a++a expression should be evaluated before return, so first version is no more able to tun in fixed space and second one definitely is winner so, in lazy environment, sometimes it's better to keep data in unevaluated form and compute it on each use, while in strict environment, CSE always win -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (2)
-
Bulat Ziganshin
-
Dinko Tenev