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

[Peter Ross]

On Mon, Jan 22, 2001 at 08:42:43PM +1100, Fergus Henderson wrote:
> I've analyzed the bug that caused an internal compiler error when
> extras/trailed_update/var.m was compiled with `-O4 --high-level-code'.
> 
> Deforestation was performance some optimizations, and then rerunning
> mode analysis, but not rerunning determinims analysis.  One of the
> deconstruction unifications was originally marked by mode analysis as
> `can_fail' and hence by determinism analysis as `semidet'.  When mode
> analysis was rerun by deforestation, the more precise insts lead to
> the unification being marked as `cannot_fail'.  However, determinism
> analysis was not rerun, so the determinism in the goal_info was still
> `semidet'.  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.

However, I believe that it would be very nice to be able to easily rerun
type, mode and determinism checking after *every* pass of the compiler.
This would be particularly useful when coding up a new module.

Pete
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------