[mercury-users] Loop optimisation and predicate specialisation and stuff.

Fergus Henderson fjh at cs.mu.oz.au
Mon Dec 22 22:39:36 AEDT 1997

[This thread is regarding optimization of the following example:
         :- pred foo(int, int, list(int), int).
         :- mode foo(in,  in,  in,        out) is det.
         foo(_, [], C, C).
         foo(A, [B | Bs], C0, C) :-
                 X = f(A),               % f/1 is a det function.
                 C1 = g(X, B, C0),
                 foo(A, Bs, C1, C).
On 22-Dec-1997, Peter Moulder <reiter at netspace.net.au> wrote:
> Andrew Bromage <bromage at cs.mu.OZ.AU> writes:
> > however there is a semantic "gotcha".
> > 
> > Suppose:
> > 
> > 	f(A) = 100/A.
> Yes, but this is just a quality-of-implementation issue.
> Implementations are allowed to be incomplete 
> (*see (mercury_ref)Semantics::, and Fergus' (?) recent post describing 
> the semantics of error/1).

You are correct.

However, the optimization would not be allowed if the user invoked the
implementation in a mode which disallowed reordering,
and every implementation must provide such a mode.

Also, if the loop had used an if-then-else rather than a switch,
then the optimization would not be allowed (the reference manual
is a bit vague on this point, but our intent has always been that
an implementation must evaluate the condition of an if-then-elses
before evaluating the `then' or the `else' branches).

Furthermore, my observation is that a fairly significant portion of
existing Mercury code assumes that code in a failing branch of a
switch will not be executed.  So performing optimizations that violate
this assumption would not be good quality-of-implementation, IMHO.
Perhaps we should in fact change the reference manual to guarantee that
this assumption holds.

Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at         |     -- the last words of T. S. Garp.

More information about the users mailing list