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

[Warwick Harvey]

Zoltan wrote:
> I wrote:
> > 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.

Sure, I understand that, but I wasn't really understanding when or why all 
this stuff was being done.  Indeed, I was misunderstanding the why, and thus 
had the when a little wrong, so I thought it *wasn't* obeying the semantics 
of the trailing operations.

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

Fine.  The only point I'll make here is that in this particular case the 
caller has *already* tested `MR_trace_from_full'.  I think you can actually 
save a little code here (no need to save `MR_trace_call_depth' in the 
`MR_trace_from_full' is FALSE branch), as well as the obvious reduction in 
the number of instructions executed if MR_trace() need not be called.  No 
claims made about relative speed though, having recently encountered a 30 or 
40% speed difference in a benchmark due to "minor" reordering of the 
generated code.  :-(

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

... except when `--trace-optimized' is specified.  But I haven't 
investigated far enough to determine whether intermodule optimisation is 
still enabled with this or not, since you provided a much better example of 
how it can happen:

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

Warwick

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