Files
mercury/tests/debugger/declarative/closure_dependency.exp2
Ian MacLarty 521967f39f Implement a second version of the subterm dependency tracking algorithm
Estimated hours taken: 20
Branches: main

Implement a second version of the subterm dependency tracking algorithm
that uses the following heuristic to speed things up: If the subterm is being
tracked through an output argument, and there is an input argument with the
same name as the output argumnet, except for a numerical suffix, then the new
algorithm will check if the subterm appears in the same position in the input
argument.  If it does then it will continue tracking the subterm in the input
argument, thus bypassing the subtree rooted at the call.  Since dereferencing a
subterm in a large structure can be expensive, the new algorithm will only try
to bypass calls to procedures it has not tried to bypass before.  The set of
procedures it has tried is reset each time a new explicit subtree or supertree
is generated.

Add a `track' command that behaves in the same way as `mark', except that
it doesn't assert that the node is erroneous or inadmissible.
Add an optional `--accurate' argument which tells the declarative debugger to
use the original tracking algorithm.
We still allow the old algorithm to be used, because there
are situations where the new algorithm could find the wrong call (i.e.
when a subterm appears in the same position in an input argument,
but the subterm in the output argument is actually bound by a descendent call
-- it just happens to be bound to the same value as the input subterm).

doc/user_guide.texi:
	Change the documentation accordingly.

browser/browse.m:
browser/browser_info.m:
browser/parse.m:
browser/declarative_user.m:
	Add a `track' command that does the same thing as a `mark' command,
	except it doesn't assert the atom to be erroneous or inadmissible.
	Allow an `--accurate' or `-a' argument for the `mark' and `track'
	commands which indicates that the old subterm dependency tracking
	algorithm should be used.
	Pass information about tracked subterms to the declarative debugger.
	Do not allow a whole atom to be tracked or marked as this doesn't
	make sense.

browser/declarative_analyser.m:
browser/declarative_debugger.m:
browser/declarative_edt.m:
browser/declarative_oracle.m:
	Implement the new tracking algorithm.

browser/term_rep.m:
	Add a predicate to dereference a subterm in another term.

mdbcomp/rtti_access.m:
	Add a predicate to find a candidate input argument on which to
	apply the new heuristic.

runtime/Mmakefile:
runtime/mercury_layout_util.h:
runtime/mercury_stack_layout.h:
trace/mercury_trace_vars.c:
trace/mercury_trace_vars.h:
	Move the function for finding the name of a variable to the runtime,
	so that it can be called from the declarative debugger.

tests/debugger/declarative/Mmakefile:
tests/debugger/declarative/nodescend_tracking.exp:
tests/debugger/declarative/nodescend_tracking.inp:
tests/debugger/declarative/nodescend_tracking.m:
	Test the new heuristic.

tests/debugger/declarative/closure_dependency.inp2:
tests/debugger/declarative/closure_dependency.exp2:
	Expect an error message when marking a whole atom.
2005-11-02 14:02:16 +00:00

88 lines
2.0 KiB
Plaintext

E1: C1 CALL pred closure_dependency.main/2-0 (det) closure_dependency.m:13
mdb> mdb> Contexts will not be printed.
mdb> echo on
Command echo enabled.
mdb> break a
0: + stop interface pred closure_dependency.a/3-0 (det)
mdb> c
E2: C2 CALL pred closure_dependency.a/3-0 (det)
mdb> f
E3: C2 EXIT pred closure_dependency.a/3-0 (det)
mdb> dd -d 3 -n 7
a(0, [100, 0], t(p([0])))
Valid? browse
browser> cd 3/1
browser> ls
p([0])
browser> mark
d([0], t(p([0])))
Valid? browse
browser> mark
Cannot track the entire atom. Please select a subterm to track.
dd> n
Found incorrect contour:
d([0], t(p([0])))
Is this a bug? y
E4: C3 EXIT pred closure_dependency.d/2-0 (det)
mdb> c
E3: C2 EXIT pred closure_dependency.a/3-0 (det)
mdb> c
E5: C4 CALL pred closure_dependency.a/3-0 (det)
mdb> f
E6: C4 EXIT pred closure_dependency.a/3-0 (det)
mdb> dd -d 3 -n 7
a(1, [100, 1], t(p([1])))
Valid? b 2
browser> mark
p([1], 100, [100, 1])
Valid? b
browser> cd 1
browser> mark
b(1, [1])
Valid? n
Found incorrect contour:
b(1, [1])
Is this a bug? y
E7: C5 EXIT pred closure_dependency.b/2-0 (det)
mdb> c
E6: C4 EXIT pred closure_dependency.a/3-0 (det)
mdb> c
E8: C6 CALL pred closure_dependency.a/3-0 (det)
mdb> f
E9: C6 EXIT pred closure_dependency.a/3-0 (det)
mdb> dd -d 3 -n 7
a(2, [100, 2], t(p([2])))
Valid? b 2
browser> mark
p([2], 100, [100, 2])
Valid? b 2
browser> mark
e(2, 100)
Valid? n
Found incorrect contour:
e(2, 100)
Is this a bug? y
E10: C7 EXIT pred closure_dependency.e/2-0 (det)
mdb> c
E9: C6 EXIT pred closure_dependency.a/3-0 (det)
mdb> c
E11: C8 CALL pred closure_dependency.a/3-0 (det)
mdb> f
E12: C8 EXIT pred closure_dependency.a/3-0 (det)
mdb> dd -d 3 -n 7
a(3, [100, 3], t(p([3])))
Valid? b 2
browser> mark
p([3], 100, [100, 3])
Valid? b
browser> cd 3
browser> cd 2
browser> ls
[3]
browser> mark
Found incorrect contour:
p([3], 100, [100, 3])
Is this a bug? y
E13: C9 EXIT pred closure_dependency.p/3-0 (det)
mdb> quit -y