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’.
When generating .d, .dep and .dv files, generate Makefile fragments that use only the features of standard make; do not assume the availability of GNU Make extensions. This can make these files significantly larger.
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 module.c file. This is primarily useful for trying to understand how the generated C 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’ option.
Do not 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’).
Set the maximum width of an error message line to N characters (unless a long single word forces the line over this limit).
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.
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 option argument. These details are: a - argument modes in unifications, b - builtin flags on calls, c - contexts of goals and types, d - determinism of goals, e - created, removed, carried, allocated into, and used regions, f - follow_vars sets of goals, g - goal feature lists, i - variables whose instantiation changes, l - pred/mode ids and unify contexts of called predicates, m - mode information about clauses, n - nonlocal variables of goals, p - pre-birth, post-birth, pre-death and post-death sets of goals, r - resume points of goals, s - store maps of goals, t - results of termination analysis, u - unification categories and other implementation details of unifications, v - variable numbers in variable names, x - predicate type information. y - structured insts in the arg-modes of unification z - purity annotations on impure and semipure goals A - argument passing information, B - mode constraint information, C - clause information, D - instmap deltas of goals (meaningful only with i), E - deep profiling information, G - compile-time garbage collection information, I - imported predicates, M - mode and inst information, P - goal id and path information, R - live forward use, live backward use and reuse possibilities, S - information about structure sharing, T - type and typeclass information, U - unify and compare predicates, X - constant structures, Z - 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.
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.h_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.
Dump the internal compiler representation of the MLDS, after the specified stage number or stage name, to module.mlds_dump.num-name.
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.