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

Zoltan Somogyi zs at cs.mu.OZ.AU
Thu Jan 27 17:53:59 AEDT 2000

> This means it could be wrong during the execution of the body of the 
> predicate, right?

There is no question of right and wrong here. The value of the ticket counter
at a given point in the program will be different with different trace levels,
but Mercury code is not supposed to depend on that; as long as the C code the
compiler emits obey the semantics of the trailing operations, it should be
all right.

> The counter also seems to be being incremented more often than necessary, 
> but the above could easily account for (all of) that.

This is precisely the difference when tracing is enabled. When we enter a call,
the debugger may retry that call. We therefore need a new ticket because
the trail may need to be rewound to restore the state it had on entry to that
call. In non-traced execution, there may be no ticket to mark that division
in the trail.

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

It is harmless: MR_trace will return immediately and not register an event
in such circumstances. Doing the test in MR_trace instead of in the callers
of MR_trace saves several megabytes of code size; given that the test in
MR_trace *will* be in the I-cache whereas the tests in the callers may not be,
it may even be faster.

This is documented in the debugger paper.

> 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?)

Intermodule optimization is irrevant, because all optimizations that change
the trace are turned off when tracing is enabled.

Local procedures can still be called from deep-traced code if their
address is ever taken and passed to deep-traced code.

However, I will see what the impact is of effectively compiling a procedure
with trace level none if (a) its module is shallow traced; (b) it is not
exported; and (c) its address is not taken. Thanks for the suggestion.

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

More information about the developers mailing list