[m-dev.] cannot_fail deconstruct -vs- goal_info determinism

[Simon Taylor]

Fergus Henderson wrote:
> On 22-Jan-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > On Mon, Jan 22, 2001 at 08:42:43PM +1100, Fergus Henderson wrote:
> > > ml_unify_gen.m was checking that the `can_fail' field in
> > > deconstruct unifications matched the determinism on the goal_info,
> > > and this check failed, leading to the call to error/1.
> > > 
> > > It would be easy to modify ml_unify_gen.m so that it doesn't make that
> > > assumption.  However, I'm not sure if that is the right solution.
> > > There's three possible solutions, and I'm not sure which is best:
> > > 
> > > 	- Document this invariant in hlds_goal.m, as an invariant that
> > > 	  must hold at all stages after determinism analysis, and modify
> > > 	  deforestation to preserve the invariant (e.g. by rerunning
> > > 	  determinism analysis after it reruns mode analysis).
> > > 
> > > 	- Document this invariant in hlds_goal.m, as an invariant that
> > > 	  must hold when generating code, and add code in simplify.m to
> > > 	  ensure that the invariant holds.  (This would match what we do
> > > 	  for the invariant that the determinism match the instmap_delta
> > > 	  with regard to at_most_zero_solns/unreachable.)
> > > 
> > > 	- Modify ml_unify_gen.m so that it doesn't depend on this
> > > 	  invariant, but instead allows the determinism in the
> > > 	  goal_info to be any conservative approximation.
> > > 
> > > Any suggestions as to which of these we should adopt?
> >
> > I suggest the second option.
> 
> A rationale would help a lot.
> 
> After thinking about it a bit, I'm inclined to go with the last
> solution.  The first option is fragile, since there might well be
> other passes of the compiler that produce code which doesn't meet that
> invariant.  As for the choice between the second and third, handling
> it in ml_unify_gen.m is easier, I think.

I agree. The second solution will still leave the determinism of the
enclosing goal as a conservative approximation, so it doesn't really
buy you much.
 
> Estimated hours taken: 3
> 
> Fix a bug that broke extras/trailed_update/samples/vqueens.m
> when compiled with `-H -O4'.
> 
> compiler/ml_code_gen.m:
> 	Export ml_gen_wrap_goal, for use by ml_unify_gen.m.
> 
> compiler/ml_unify_gen.m:
> 	Handle deconstruct unifications where the goal_info determinism
> 	doesn't match the can_fail field of the deconstruct by calling
> 	ml_gen_wrap_goal, rather than aborting.

That looks fine.

Simon.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------