[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 128.250.37.3 | -- the last words of T. S. Garp.
More information about the users
mailing list