When compiling, write program dependency information to be used to avoid unnecessary recompilations if an imported module’s interface changes in a way which does not invalidate the compiled code. ‘--smart-recompilation’ does not yet work with ‘--intermodule-optimization’.
Generate code that includes the specified level of execution tracing. The level should be one of ‘none’, ‘shallow’, ‘deep’, ‘rep’ and ‘default’. See Debugging.
Do not disable optimizations that can change the trace.
Do not disable optimizations that can distort deep profiles.
When the trace level is ‘deep’, the compiler normally preserves the values of variables as long as possible, even beyond the point of their last use, in order to make them accessible from as many debugger events as possible. However, it will not do this if this option is given.
Delay the deaths of variables only when the number of variables in the procedure is no more than N. The default value is 1000.
Enable stack traces through predicates and functions with higher-order arguments, even if stack tracing is not supported in general.
Output a bytecode form of the module for use by an experimental debugger.
Output comments in the generated target language file. This is primarily useful for trying to understand how the generated target language code relates to the source code, e.g. in order to debug the compiler. The code may be easier to understand if you also use the ‘--no-llds-optimize’ or ‘--no-mlds-optimize’ options.
Put source line numbers in the generated code. The generated code may be in C (the usual case) or in Mercury (with ‘--convert-to-mercury’).
Do not put source line numbers into the generated code around inclusions of foreign language code.
Put source line numbers in the generated C header files. This can make it easier to track down any problems with C code in foreign_decl pragmas, but may cause unnecessary recompilations of other modules if any of these line numbers changes (e.g. because the location of a predicate declaration changes in the Mercury source file).
Set the maximum width of an error message line to N characters (unless a long single word forces the line over this limit). Specifying ‘--no-max-error-line-width’ removes the limit.
Print error messages in descending order of their line numbers, instead of the usual ascending order. This is useful if you want to work on the last errors in a file first.
Write out a list of the types, insts, modes, predicates, functions, typeclasses and instances defined in the module to module.defns.
Write out a list of the predicates and functions defined in the module, together with the names of the files containing them and their approximate line counts, to module.defn_line_counts. The list will be ordered on the names and arities of the predicates and functions.
Write out a list of the predicates and functions defined in the module, together with the approximate line numbers of their first and last lines, to module.defn_extents. The list will be ordered on the starting line numbers of the predicates and functions.
Construct the call tree of the predicates and functions defined in the module. Each node of this tree is a local predicate or function, and each node has edges linking it to the nodes of the other local predicates and functions it refers to. Write out to module.local_call_tree a list of these nodes. Put these nodes into the order in which they are encountered by a depth-first left-to-right traversal of the bodies (as reordered by mode analysis), of the first procedure of each predicate or function, starting the traversal at the exported predicates and/or functions of the module. List the callees of each node in the same order. Write a flattened form of this call tree, containing just the predicates and functions in the same traversal order, to module.local_call_tree_order.
Write out information about the representations of all types defined in the module being compiled to module.type_repns.
Write out information about the representations of all types visible in the module being compiled to module.type_repns.
Write out the dependency graph to module.dependency_graph.
Write out the imports graph to module.imports_graph. The imports graph contains the directed graph module A imports module B. The resulting file can be processed by the graphviz tools. Effective only if ‘--generate-dependencies’ is also specified.
Dump the HLDS (a high-level intermediate representation) after the specified stage number or stage name to module.hlds_dump.num-name. Stage numbers range from 1 to 599; not all stage numbers are valid. If a stage number is followed by a plus sign, all stages after the given stage will be dumped as well. The special stage name ‘all’ causes the dumping of all stages. Multiple dump options accumulate.
With ‘--dump-hlds’, include extra detail in the dump. Each type of detail is included in the dump if its corresponding letter occurs in the options argument. These details are:
argument modes in unifications
builtin flags on calls
contexts of goals and types
determinism of goals
created, removed, carried, allocated into, and used regions
follow_vars sets of goals
goal feature lists
variables whose instantiation changes
pred/mode ids and unify contexts of called predicates
mode information about clauses
nonlocal variables of goals
pre-birth, post-birth, pre-death and post-death sets of goals
resume points of goals
store maps of goals
results of termination analysis
unification categories and other implementation details of unifications
variable numbers in variable names
predicate type information
structured insts in the arg-modes of unification
purity annotations on impure and semipure goals
argument passing information
mode constraint information
instmap deltas of goals (meaningful only with ‘i’)
deep profiling information
compile-time garbage collection information
restrict the output of type table entries to local types only
mode and inst information
dependency and dependency ordering information
goal id and path information
live forward use, live backward use and reuse possibilities
information about structure sharing
type and typeclass information
unify and compare predicates
print insts using indentation to explain structure
information about globals structs representing call and answer tables
With ‘--dump-hlds’, restrict the output to the HLDS of the predicate or function with the specified pred id. May be given more than once.
With ‘--dump-hlds’, restrict the output to the HLDS of the predicate or function with the specified name. May be given more than once.
Dump at most N insts in each inst table.
Dump insts in an inst table only if their size does not exceed N.
Append the given suffix to the names of the files created by the ‘--dump-hlds’ option.
Create a file for a HLDS stage even if the file notes only that this stage is identical to the previously dumped HLDS stage.
Dump the MLDS (a C-like intermediate representation) after the specified stage number or stage name. The MLDS is converted to a C source file/header file pair, which is dumped to module.c_dump.num-name and module.mih_dump.num-name. Stage numbers range from 1 to 99; not all stage numbers are valid. The special stage name ‘all’ causes the dumping of all stages. Multiple dump options accumulate. This option works only in MLDS grades that target C.
Dump the MLDS (medium level intermediate representation) of the predicate or function with the specified name at the stages specified by the ‘--dump-mlds’ option. The dump file will consist of the predicates and functions named by all the occurrences of this option (there may be more than one), and nothing else.
Dump the internal compiler representation of the MLDS, after the specified stage number or stage name, to module.mlds_dump.num-name. This option works in all MLDS grades.
Perform constraint based mode analysis on the given modules. At the moment, the only effect of this is to include more information in HLDS dumps, to allow the constraint based mode analysis algorithm to be debugged.
Ask for the simplified variant of constraint based mode analysis, in which there is only one constraint variable per program variable, rather than one constraint variable per node in the inst graph of a program variable. This option is ignored unless ‘--mode-constraints’ is also given.
Output information about the performance of the constraint based mode analysis algorithm.
Specifies the number of times the mode analysis algorithm should run. More repetitions may smooth out fluctuations due to background load or clock granularity. This option is ignored unless ‘--benchmark-modes’ is also given.