[m-rev.] diff: reset contains_trace_goal if necessary

Mark Brown mark at csse.unimelb.edu.au
Thu Nov 9 14:37:44 AEDT 2006


On 08-Nov-2006, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> On Mon, Nov 06, 2006 at 06:19:57PM +1100, Zoltan Somogyi wrote:
> > compiler/simplify.m:
> > 	Finish something I left undone when I added trace goals. When a trace
> > 	goal is deleted from the HLDS, the goals that used to contain it still
> > 	have a feature that says they contain a trace goal, which inhibits
> > 	their optimization (since in some respects they are treated as if they
> > 	were impure). This diff resets that feature for those goals.
> > 
> 
> Is the behaviour of not optimising away code that contains trace goals wise?
> This behaviour might mean that the act of adding a trace goal to try and
> diagnose a bug may cause the bug to disappear.  Consider a bug involving
> a false purity promise where the promised pure code is optimised away
> by the compiler.  Now suppose I want to test if the promised pure code
> is being run in my application.  I add a trace goal and run my program.
> Now all of a sudden my program does the correct thing, because the
> code that was falsly promised pure is now run.

This is part of the danger of using promise_pure.  An alternative (and
better) way of helping users debug this problem would be to give a warning
whenever a promised pure goal is optimised away.

> 
> This behaviour also means trace goals are not useful for determining how
> many times a goal was run in optimised code, something that might be
> useful for performance profiling.

If the goal is optimised away, then the number of times it is run would be
zero.  To see whether or not it is run at all, the above warning would
suffice.

Offhand, I can't think of any other optimisations that would cause this
kind of problem.  Anyone?

> 
> I think you should remove the feature that prevents code containing
> trace goals from being optimised away.  If I add a trace goal then I
> only want to see the effects of the trace goal if the conjunct it
> appears is run under normal circumstances and I definitely don't want
> the behaviour of my program to change, besides the extra output
> generated by the trace goals.

For domain-specific debugging (e.g., the trace events for the G12
propagation engine) you definitely don't want them optimised away.
If they are, then the trace events may no longer match the trace
sequence specification.  Debugging/visualization tools could therefore
break.  But you still want the code compiled without tracing to be
optimised as much as possible.

(BTW, does `--trace-optimised' have any effect on trace goals?)

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list