[m-dev.] for review: fix for a bug reported by Warwick

[Fergus Henderson]

On 27-Jan-2000, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> Zoltan wrote:
> > > Unfortunately, it doesn't quite work.  It appears (at least in some cases) 
> > > to restore the stack pointer and before testing the saved value of 
> > > `MR_trace_from_full', which means it's looking in the wrong part of the 
> > > stack, and hence sometimes making the wrong choice.
> > 
> > Yes, you are right. However, it seems to me that the problems you point out
> > in the rest of the review fully account for this behavior, and so the obvious
> > fix "should" work. I am attaching the full modified diff for you to test.
> 
> Yes, this appears to have fixed that problem, and it appears to work, at 
> least on the examples I've tried so far.  However, looking closer I think 
> there're still problems.  :-(
> 
> Assuming that the save/restore of the ticket counter is so that the tracing 
> code doesn't interfere with the "real" code, surely the restore should be 
> immediately after the tracing code, not at the end of the predicate?  

The ticket counter is not saved/restored, so I'm not sure what you
are talking about here.

The debugging code checkpoints the trail state (i.e. allocates a trail ticket
and saves the current trail pointer) so that the state can be restored if
the user does a "retry" command in the debugger.

For det/semidet code, the trail ticket that was allocated is discarded at the
end of the procedure, since once the procedure has returned, it cannot
be retried.  For nondet code, the trail ticket can only be discarded
once the procedure has failed.

> Also, in my struggle to understand all this tracing stuff, I am wondering 
> why in shallow-traced code, when `MR_trace_from_full' is FALSE, MR_trace() 
> is still called.  My understanding is no events should be generated in this 
> case?  Or is the call to MR_trace() "harmless" here?

I think your understanding is correct.
Perhaps you could show the generated code which you think is wrong?

> Presumably also one 
> could optimise the code for predicates which aren't exported when using 
> shallow tracing, because they can't possibly be called from deep-traced 
> code?  (Or can they, through intermodule optimisation?)

Yes, predicates which are not exported can be called through
intermodule optimization, or from nested modules,
but in those cases they are marked as `opt_exported'
or `exported_to_children', so we could detect those cases
fairly easily.  However predicates can also have their
address taken and be called indirectly.  I think we now
record which predicates have their address taken, so it might
now be fairly easy to do that optimization for
non-exported procedures whose address is not taken
and which are not implementations of type class method.

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