[m-rev.] for review: cleanup mercury_trace_declarative.c
Ian MacLarty
maclarty at cs.mu.OZ.AU
Mon Apr 11 17:04:33 AEST 2005
On Sun, Apr 10, 2005 at 05:51:54PM +1000, Julien Fischer wrote:
>
> On Sun, 10 Apr 2005, Ian MacLarty wrote:
>
> > In this diff I have also included compiler generated unifications in the
> > annotated trace. The declarative debugger wont ask questions about these
> > because they are automatically trusted, but they are needed in case a subterm
> > needs to be tracked though a complicated unification.
> >
> > I was unable, however to create a test case that caused a __Unify__ predicate
> > to be generated which produced output. Are all compiler generated unifications
> > just test unifications?
>
> I'm pretty sure that all of the compiler generated unification
> predicates are (in, in). (The code that generates them is in
> compiler/unify_proc.m).
>
In this case I will not include compiler generated unifications in the
annotated trace, since they cannot be responsible for generating a subterm.
> > If not could someone give me an example of a
> > complicated unification which produces output and for which the compiler
> > generates a seperate procedure? All the complicated unifications in the
> > tests directories seem to be test-unifications (i.e. unifications that produce
> > no output).
> >
> > Cheers,
> > Ian.
> >
> > Estimated hours taken: 5
> > Branches: main
> >
> > Clean up trace/mercury_trace_declarative.c by breaking MR_trace_decl_debug into
> > several functions. This function was getting very big and difficult to
> > maintain.
> >
> > trace/mercury_trace_declarative.c:
> > Break MR_trace_decl_debug into MR_trace_edt_build_sanity_check, which
> > checks that we haven't passed the last event for the portion of the
> > trace being constructed; MR_trace_include_event, which decides if an
> > event should be included in the annotated trace and resets the depth
> > if the event is at the top of an area to be materialized;
> > MR_trace_calculate_event_depth, which calculates the depth in the EDT
> > of the current event and sets the global MR_edt_depth appropriately;
> > And MR_trace_construct_node, which constructs a node in the annotated
> > trace.
> >
> That would read better as:
>
> Decompose MR_trace_decl_debug into smaller functions:
> MR_trace_edt_build_sanity_check, ... etc
>
Done.
> > Uncomment the code that includes compiler generated unifications in the
> > annotated trace.
>
> The log message should mention why it is ok to uncomment this code now.
>
This code has now been removed.
> > +static MR_bool MR_trace_include_event(const MR_Proc_Layout *entry,
> > + MR_Event_Info *event_info,
> > + MR_Code **jumpaddr);
> > +static MR_Unsigned MR_trace_calculate_event_depth(
> > + MR_Event_Info *event_info);
> > +static void MR_trace_construct_node(MR_Event_Info *event_info);
> >
> > MR_bool MR_trace_decl_assume_all_io_is_tabled = MR_FALSE;
> >
> > @@ -339,6 +346,23 @@
> > MR_bool MR_trace_decl_in_dd_dd_mode = MR_FALSE;
> >
> > /*
> > +** We filter out events which are deeper than a certain
> Delete the word "certain".
>
Okay.
> > +** limit given by MR_edt_max_depth. These events are
> > +** implicitly represented in the structure being built.
> > +** Adding 1 to the depth limit ensures we get all the
> > +** interface events inside a call at the depth limit.
> > +** We need these to build the correct contour.
> > +** Note that interface events captured at max-depth + 1
> Is that max minus depth or max_depth?
>
max dash depth. I have changed it to "the maximum depth plus one".
> > +** will have their at-depth-limit flag set to no. This
> > +** is not a problem, since the parent's flag will be yes,
> > +** so there is no chance that the analyser could ask for the
> > +** children of an interface event captured at max-depth + 1,
> > +** without the annotated trace being rebuilt from the parent
> > +** first.
> Make that last bit a separate sentence. ie.
>
> There is no chance that the analyser could ask ...
>
Okay.
>
> > +*/
> > +#define MR_TRACE_EVENT_TOO_DEEP(depth) depth > MR_edt_max_depth + 1
> > +
> You should parantheses around the body of that macro.
>
Okay.
> > +
> > + trace_suppress = entry->MR_sle_module_layout->MR_ml_suppressed_events;
> > + if (trace_suppress != 0) {
> > + /*
> > + ** We ignore events from modules that were not compiled
> > + ** with the necessary information. Procedures in those
> > + ** modules are effectively assumed correct, so we give
> > + ** the user a warning.
> > + */
> That comment is a little unclear, perhaps the following:
>
> We ignore events from modules that were not compiled with
> the necessary information. In the absence of such information
> we have to asssume that procedures in those modules are correct.
> We issue a warning to let the user know that this has occurred.
>
I think the original version is clearer.
> > + MR_Event_Info *event_info, MR_Code **jumpaddr)
> > +{
> > /*
> > ** Filter out events for compiler generated procedures.
> > - ** XXX Compiler generated unify procedures should be included
> > + ** Compiler generated unify procedures should be included
> > ** in the annotated trace so that sub-term dependencies can be
> You should s/sub-term/subterm/ in the line above.
Done.
>
> That looks ok otherwise.
>
Cheers,
Ian.
--------------------------------------------------------------------------
mercury-reviews mailing list
post: mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------
More information about the reviews
mailing list