[m-dev.] Deforestation question

[Ralph Becket]

>From Simon Taylor on 12/02/2001 23:42:01
> 
> As far as I can tell, deforestation does nothing to either case
> other than some unrolling of the foldl loop. I wouldn't expect
> it to do more than that.

So when I make use of io__read_char, say, and crank up the optimization
and the compiler sees that there's no need to construct io__results all
over the shop when the calls to io__read_char are immediately followed
by a switch, this is a consequence of inlining and unrolling rather
than deforestation?

> > Perhaps it would not be hard to change the deforestation heuristics
> > so that the deforestation pass will optimize cases like this...
> > Simon, what do you think?
> 
> What Ralph wants is the unboxing optimization that we've
> discussed many times but have never implemented because we
> couldn't come up with a decent heuristic.

The people working on ML here do various things like flatten

	:- type list(pair(T1, T2))

into

	:- type list_567(T1, T2) ---> nil ; cons(T1, T2, list_567(T1, T2)).

According to them it's a very valuable optimization (sometimes it's wrong,
but they win more than they lose).

I take it then that the problem is not coding the transformation, but
working out when best to apply it?  How do the OCaml people etc. deal
with this?

For my own part, it's the sort of thing that would make a noticeable
difference even if it just worked for say the first few inner levels of
looping.

Ralph

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------