mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-12 12:26:29 +00:00
036b97ff7d
Common subexpression elimination (cse) declines to do its job of transforming
(
X = f(A1, ..., An),
goal A
;
X = f(B1, ..., Bn),
goal B
)
into
X = f(X1, ..., Xn),
(
A1 = X1, ..., An = Xn,
goal A
;
B1 = X1, ..., Bn = Xn,
goal B
)
when the insts of some of X's arguments are at least partially unique,
because mode analysis cannot track uniqueness through the extra unifications
that this transformation introduces. When this happens, and the procedure
this code is in does not match its declared determinism, generate a message
that gives this fact as a possible reason for that determinism mismatch.
This fixes Mantis bug #496 to the extent that we *can* fix it
without rewriting the whole of mode analysis.
compiler/hlds_pred.m:
Provide a slot in the proc_info for recording whether cse has declined
to pull a common unification out of a branched control structure because
of this concern, and if so, at what locations in the source code.
An unrelated change: move a slot used only by constraint-based mode
analysis, which is never enabled, from the proc_info to the proc_sub_info.
This should improve both speed and memory consumption, though very
slightly.
compiler/cse_detection.m:
Record each such location in this slot.
Doing this requires a change in approach. Previously, we did not try
to pull a unification out of any branch of a branched control structure
if it involved (partially or wholly) unique arguments. However, doing
this in just one branch cannot possibly affect the output of cse detection,
since it pulls a unification out of a branch only if can pull the same
unification out of all the other branches as well.
Our new approach is to transform branched control structures regardless
of uniqueness, and then *undo* the transformation (simply by discarding
its result) if it involves unique arguments. It is such undoing that we
record in the proc_info.
compiler/switch_detection.m:
Conform to the new approach.
compiler/hlds_out_pred.m:
Print the contents of the new slot in HLDS dumps.
compiler/det_report.m:
If the actual determinism of a procedure, as computed by determinism
analysis, does not match its declared determinism, *and* if the proc_info's
new slot says that cse declined to pull some common unifications
out of a branched control structure, then mention that fact, and
the usual fix, as a possible explanation of the determinism problem.
tests/invalid/bug496.{m,err_exp}:
The Mantis test case.
tests/invalid/Mmakefile:
Enable the new test case.
The Mercury test suite is (dis)organized into a directory hierarchy.
`mmake' will run the tests in the directory it is
invoked in and all subdirectories of that subdirectory.
Use `mmake runtests_local' to just run the local tests without
the subdirectories.
To run just the tests that failed in a previous test run,
use `mmake ERROR_FILE=FILE', where FILE is a copy of the
runtests.errs file from the previous run.
Both the bootcheck script and the nightly script use `mmake'
to run all the tests.
Unless otherwise stated, the tests in each directory compile
the test programs and compare their output against hand-coded
`.exp' (or `.exp2', `.exp3', etc) files.
NOTE: if you add a new (sub)directory to the test suite then you
may need to update the value of the variable `all_test_dirs'
in tools/bootcheck.
analysis
This directory is for testing the intermodule analysis framework.
benchmarks
This directory contains Mercury versions of the benchmarks.
debugger
This directory is for testing mdb, the Mercury debugger.
Programs are compiled with deep tracing turned on. The
tests in this directory are not performed if the base grade
is `jump' or `fast'.
debugger/declarative
This directory is for testing the declarative debugging
features of mdb.
general
hard_coded
These directories are for general test cases.
(It might be a good idea to split this into tests
of particular features and regression tests that check
for old bugs. But for the moment, just about everything
goes in here.)
The historical reason for the separate `general' and `hard_coded'
directories was that the tests in `general' worked with NU-Prolog
and compared the Mercury output with the NU-Prolog output,
but the tests in `hard_coded' didn't work with NU-Prolog, so
their expected output needed to be hard-coded. We no longer
support compilation with NU-Prolog, so everything goes
in hard_coded now.
recompilation
This directory contains tests of the smart recompilation system.
As well as checking for the correct output from the test
programs these tests also examine the `.err' files to
make sure that all necessary recompilations are performed.
valid
This directory is for test cases that are not complete
programs. We just check that the files compile.
invalid
This directory is for test cases that are invalid
programs. We check that the files do *not* compile,
and check that the errors match those in the hand-written
`.err_exp' file.
warnings
This directory is for tests of compiler warnings. These work by
comparing the warnings emitted by the compiler with those given
in the hand-written `.exp' file.
term
This directory tests the compiler's termination analyser. These
tests work by comparing the contents of the .trans_opt file emitted
by the compiler with the hand-written `.trans_opt_exp' file.
This directory is also used for testing the compiler's exception
analysis.
trailing
This directory contains tests that make use of the trail.
These tests are only run in trailing grades.