[m-rev.] for review: fix purity in tabling and optimization passes
Simon Taylor
stayl at cs.mu.OZ.AU
Tue Mar 27 11:49:41 AEST 2001
On Mon, Mar 26, 2001 at 10:35:15AM +1000, Fergus Henderson wrote:
> On 24-Mar-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> >
> > compiler/deforest.m:
> > Use the same method as inlining.m to work out whether
> > a procedure can be inlined. Don't inline predicates which
> > are promised pure because the extra impurity which
> > will be propagated through the goal will stop deforestation
> > working on the goal.
>
> What about predicates which are inferred semipure and promised pure?
> For those, the extra impurity (or perhaps I should say the extra
> semi-impurity) shouldn't prevent deforestation, should it?
> It seems to me that the right condition to check here
> is not whether the predicate was promised pure, but whether
> the predicate body is impure.
Deforestation is a bit conservative with regard to impurity.
The main reason for this is that it is difficult to keep the
purity markers up to date while performing the goal rearrangement
that deforestation does. Because the modes and determinism
of a procedure are always a conservative approximation of the
modes and determinism of the body of the procedure, it is not
neccessary to push the extra information through the goal
(although it is desirable). With predicates which are promised
pure, the declared purity is not a conservative approximation to
the actual purity, so the extra information does need to be propagated
through the entire goal, which is not simple when deforestation only
has a handle on a sub-goal.
> > ( { VerboseErrors = yes } ->
> > prog_out__write_context(Context),
> > { pred_info_get_is_pred_or_func(PredInfo, PredOrFunc) },
> > io__write_string(" This "),
> > hlds_out__write_pred_or_func(PredOrFunc),
> > - io__write_string(
> > - " does not invoke any impure or semipure code,\n"
> > - ),
> > + io__write_string(" does not invoke any "),
> > + io__write_string(CodeStr),
> > + io__write_string(",\n"),
>
> I think the word "code" got dropped there.
Fixed.
> > +:- type post_typecheck_message
> > + ---> error(post_typecheck_error)
> > + ; warning(post_typecheck_warning)
> > + .
> > +
> > +:- type post_typecheck_messages == list(post_typecheck_message).
> > +
> > +:- type post_typecheck_error
> > + ---> missing_body_impurity_error(prog_context, pred_id)
> > + ; impure_closure(prog_context, purity)
> > + ; impure_unification_expr_error(prog_context, purity)
> > + ; aditi_builtin_error(aditi_builtin_error)
> > + .
> > +
> > +:- type post_typecheck_warning
> > + ---> unnecessary_body_impurity_decl(prog_context, pred_id, purity).
>
> Hmm, should all go in post_typecheck.m rather than purity.m?
> Or should those categories be renamed purity_error, purity_warning, etc.?
I didn't want to call the category purity_error because they aren't all
purity errors. The name is a little misleading, but I couldn't think of
anything better.
> > --- doc/reference_manual.texi 2001/03/15 06:32:06 1.203
> > +++ doc/reference_manual.texi 2001/03/24 02:10:09
> > @@ -5846,20 +5846,24 @@
> > +In some cases the impurity of a predicate's body is an implementation
> > +detail which should not be exposed to callers. These predicates should
> > +be considered to be pure or semipure even though they call impure or
> > +semipure predicates. The only way for the programmer to stop the
> > +propagation of impurity is to explicitly promise that the predicate
> > +or function is pure or semipure.
>
> s/should be considered/are/
Done.
Simon.
--- deforest.m 2001/03/26 14:11:04 1.1
+++ deforest.m 2001/03/26 14:11:23
@@ -617,6 +617,8 @@
% promised pure because the extra impurity propagated
% through the goal when such predicates are inlined
% will defeat any attempt at deforestation.
+ % XXX We should probably allow deforestation of
+ % semipure goals.
{ InlinePromisedPure = no },
{ pred_info_get_markers(PredInfo, CallerMarkers) },
{ \+ inlining__can_inline_proc(PredId, ProcId, BuiltinState,
@@ -655,6 +657,8 @@
;
%
% Give up if there are any impure goals involved.
+ % XXX We should probably allow deforestation of
+ % semipure goals.
%
( { list__member(ImpureGoal, BetweenGoals) }
; { ImpureGoal = EarlierGoal }
@@ -1541,6 +1545,8 @@
% promised pure because the extra impurity propagated
% through the goal when such predicates are inlined
% will defeat any attempt at deforestation.
+ % XXX We should probably allow deforestation of
+ % semipure goals.
{ InlinePromisedPure = no },
{ inlining__can_inline_proc(PredId, ProcId, BuiltinState,
InlinePromisedPure, CallerMarkers, ModuleInfo) },
--- purity.m 2001/03/26 13:35:58 1.1
+++ purity.m 2001/03/27 01:46:50
@@ -1083,7 +1083,7 @@
hlds_out__write_pred_or_func(PredOrFunc),
io__write_string(" does not invoke any "),
io__write_string(CodeStr),
- io__write_string(",\n"),
+ io__write_string(" code,\n"),
prog_out__write_context(Context),
io__write_string(" so there is no need for a `"),
io__write_string(Pragma),
@@ -1119,6 +1119,8 @@
io__write_string(".\n")
).
+ % Errors and warnings reported by purity.m and post_typecheck.m
+ % for problems within a goal.
:- type post_typecheck_message
---> error(post_typecheck_error)
; warning(post_typecheck_warning)
--- reference_manual.texi 2001/03/26 13:14:15 1.1
+++ reference_manual.texi 2001/03/26 13:24:50
@@ -5847,11 +5847,10 @@
propagated up from callee to caller through the program.
In some cases the impurity of a predicate's body is an implementation
-detail which should not be exposed to callers. These predicates should
-be considered to be pure or semipure even though they call impure or
-semipure predicates. The only way for the programmer to stop the
-propagation of impurity is to explicitly promise that the predicate
-or function is pure or semipure.
+detail which should not be exposed to callers. These predicates are
+pure or semipure even though they call impure or semipure predicates.
+The only way for the programmer to stop the propagation of impurity is to
+explicitly promise that the predicate or function is pure or semipure.
Of course, the Mercury compiler cannot verify that the predicate's
purity matches the promise, so it is the programmer's responsibility
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list