mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-15 22:03:26 +00:00
02b9dceb8f
Estimated hours taken: unknown, but months (almost all by dmo) Branches: main Move changes in the compiler on the mode-constraints branch onto the trunk. compiler/top_level.m: Add the new package mode_robdd. compiler/check_hlds.m: Add the new modules within the check_hlds.m package: mode_constraints, mode_constraint_robdd and mode_ordering. compiler/hlds.m: Add the new modules within the hlds.m package, hhf and inst_graph. compiler/hhf.m: This new module implements the transformation from our usual superhomogeneous form to the hyperhomogeneous form required by constraint based mode analysis. compiler/inst_graph.m: This new module computes the instantiation graphs required by constraint based mode analysis. compiler/hlds_goal.m: Add an extra slot into goal_infos for use by constraint based mode analysis, and the predicates required to manipulate it. compiler/hlds_pred.m: Add two extra slots into pred_infos and one extra slot into proc_infos for use by constraint based mode analysis, and the predicates required to manipulate them. compiler/mercury_compile.m: Invoke the constraint based mode analysis pass if the options call for it. compiler/mode_constraints.m: This new module implements the top level of the constraint based mode analysis algorithm: it finds the constraints and adds them to the constraint store, and invokes other modules to find solutions and process them. compiler/mode_ordering.m: This new module processes solutions of constraint systems by trying to find execution orders for conjunctions that are consistent with the assignment of producers represented by a such a solution. compiler/mode_constraint_robdd.m: This new module provides a useful interface to operations on robdds used for constraint based mode analysis. The actual implementation uses one or two of the mode_robdd.X.m modules. compiler/mode_robdd.m: New top-level package to hold the modules listed below, which deal with robdd based solvers for the constraint systems generated by mode analysis. compiler/mode_robdd.check.m: This new module invokes two of the modules below and compares their results. If one of the modules is known to be good, this is useful for debugging the other. compiler/mode_robdd.r.m: compiler/mode_robdd.tfeir.m: compiler/mode_robdd.tfeirn.m: compiler/mode_robdd.tfer.m: compiler/mode_robdd.tfern.m: compiler/mode_robdd.tfr.m: These new modules each implement robdd based constraint solvers. They differ in the amount of information they keep in the robdd versus how much information they keep in Mercury data structures. The naming scheme assigns a letter to each kind of information we are concerned about, and includes that letter in the name the Mercury data structure has a separate field for that kind of information. The mapping is: r: robdd (present in all variants) tf: variables known to be true or false e: variable equivalences i: variable implications. n: normalization Normally only one of these would be linked in, or two if mode_robdd.check.m is being used to compare two of these modules. compiler/mode_robdd.equiv_vars.m: This module implements utility operations involving sets of equivalent variables. compiler/mode_robdd.implications.m: This module implements utility operations involving implications among variables. compiler/mode_robdd.prop.m: Experimental module; currently unused. Committed only to preserve its history. compiler/goal_path.m: Add a variant of an existing predicate needed by constraint based mode analysis. compiler/hlds_out.m: Print out the components added to the HLDS by this change if the appropriate signal character is present in the revelant option. compiler/handle_options.m: Add the signal for printing mode constraints to the names of the usual dumping aliases. They have no effect unless constraint based mode analysis is enabled. compiler/options.m: Add the options controlling the experimental mode constraints pass. doc/user_guide.texi: Document the options controlling the experimental mode constraints pass for implementors. compiler/notes/compiler_design.html: Document the new modules, and fix some old errors.
53 lines
1.6 KiB
Mathematica
53 lines
1.6 KiB
Mathematica
%-----------------------------------------------------------------------------%
|
|
% Copyright (C) 2002-2004 The University of Melbourne.
|
|
% This file may only be copied under the terms of the GNU General
|
|
% Public License - see the file COPYING in the Mercury distribution.
|
|
%-----------------------------------------------------------------------------%
|
|
%
|
|
% This package contains the top-level stuff that uses all the
|
|
% other packages. In particular it contains the module mercury_compile.m,
|
|
% which defines main/2, and which invokes all the other parts of the
|
|
% Mercury compiler.
|
|
%
|
|
|
|
:- module top_level.
|
|
:- interface.
|
|
|
|
% the front-end phases
|
|
:- import_module check_hlds.
|
|
:- import_module hlds.
|
|
:- import_module mode_robdd.
|
|
:- import_module parse_tree.
|
|
:- import_module transform_hlds.
|
|
|
|
% back-ends that we currently use or plan to use
|
|
:- import_module aditi_backend.
|
|
:- import_module ll_backend.
|
|
:- import_module ml_backend.
|
|
|
|
% incomplete back-ends
|
|
:- import_module bytecode_backend.
|
|
|
|
% misc utilities
|
|
:- import_module backend_libs.
|
|
:- import_module libs.
|
|
|
|
:- include_module mercury_compile.
|
|
|
|
% XXX It would be nicer to define `main' in top_level.mercury_compile,
|
|
% rather than defining it here. But that doesn't work with the
|
|
% Mercury compiler's .NET back-end, which assumes that main is defined
|
|
% in the program's top-level module.
|
|
:- use_module io.
|
|
:- pred main(io.state::di, io.state::uo) is det.
|
|
|
|
:- implementation.
|
|
|
|
:- use_module top_level.mercury_compile.
|
|
|
|
main --> top_level.mercury_compile.real_main.
|
|
|
|
:- end_module top_level.
|
|
|
|
%-----------------------------------------------------------------------------%
|