Roman
You wrote:
| 4. No fixed point analysis
|
| I think we talked about this briefly at some point; in any case, this turns
out to be one of the biggest
| problems. Consider
|
| foo :: Maybe Int -> Int -> Int
| foo (Just m) 0 = 0
| foo x@(Just m) n = foo x (n-m)
|
| SpecConstr doesn't get rid of the Just because it assumes that x must be
boxed which is obviously not
| the case here.
As you say, the idea was to avoid passing just 'm', in place of (Just m) if the
body of the function needed the (Just m) value, perhaps to pass to some other
function. If we pass 'm' alone, the function might need to rebox it to create
(Just m).
However, as you point out, this is often over-conservative. Furthermore, the
strictness analyser has the same problem:
f p@(a,b) = ...
If we pass just 'a' and 'b' to the worker, it might need to rebox the pair to
create (a,b).
A more sophisticated analysis might figure out precisely the cases in which
this could happen, but the strictness analyser does no such analysis; it just
passes 'a' and 'b', and hopes for the best.
Rather than do fancy things with a Rebox class, I think it's better for now to
make SpecConstr more aggressive, just like the strictness analyser, so that it
does not care about reboxing. I did this a week or two ago, but I think I
forgot to tell you. The above 'foo' now compiles to a nice tight loop.
Can you try your other examples (without Rebox jiggery pokery)? If we find
programs that go bad because of reboxing, we can try a more sophisticated
analysis.
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
