> Thank you Edward. I am aware of these requirements - my problem is writing
> the code in which these
> will always hold (I'm optimizing Cmm and hand-written Cmm files tend to cause
> many problems that
> don't appear in automatically generated Cmm). Having a debugging tool in form
> of Fuel would be
> helpful for me, because instead of getting a freeze and seeing no output from
> -ddump-cmm I would
> see incorrectly transformed Cmm that would allow me to track bugs more easily.
In that case, I would recommend taking a look at when -dopt-fuel got removed
and seeing if you can put it back in. I quite liked this feature and it is
too bad it is gone.
> > • The transfer function must be monotonic: given a more infor-
> > mative fact in, it must produce a more informative fact out.
>
> I spent some considerable time thinking about this. Consider a simple example
> of copy propagation.
> Let's assume that { x = NAC }, i.e. we know that x has been defined earlier
> but is Not-A-Constant
> and so we cannot rewrite it. Now we have something llike this:
>
> x := 3;
> y := x;
>
> Here we are allowed to rewrite y := x with y := 3, because after first
> statement we learn that { x
> = 3 }. Now consider this:
>
> x := 3;
> x := very_unsafe_stg_call();
> y := x;
>
> Here, after the first statement we learn that { x = 3 }, but after the second
> one we learn once
> again that x is NAC and so we are not allowed to rewrite statement y := x. So
> the value of x can
> change from NAC to a constant and from constant to a NAC. Is such a transfer
> function monotonic?
This is a point of confusion; I got confused about this when
I was working on Hoopl.
What is meant by a transfer function over instruction i is monotonic is:
if x <= y
then f_i(x) <= f_i(y)
It says nothing about the "change" in x as you move along the
statements.
Thus, for your example, very_unsafe_stg_call always puts x to be
NAC; this is trivially monotonic since NAC <= NAC.
Edward
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
