9.5 Auxiliary output options

--smart-recompilation

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’.

--trace-level level

Generate code that includes the specified level of execution tracing. The level should be one of ‘none’, ‘shallow’, ‘deep’, ‘rep’ and ‘default’. See Debugging.

--trace-optimized

Do not disable optimizations that can change the trace.

--profile-optimized

Do not disable optimizations that can distort deep profiles.

--no-delay-death

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-death-max-vars N

Delay the deaths of variables only when the number of variables in the procedure is no more than N. The default value is 1000.

--stack-trace-higher-order

Enable stack traces through predicates and functions with higher-order arguments, even if stack tracing is not supported in general.

--generate-bytecode

Output a bytecode form of the module for use by an experimental debugger.

--auto-comments

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.

-n-

--no-line-numbers

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’).

--no-line-numbers-around-foreign_code

Do not put source line numbers into the generated code around inclusions of foreign language code.

--line-numbers-for-c-headers

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).

--max-error-line-width N

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.

--show-definitions

Write out a list of the types, insts, modes, predicates, functions, typeclasses and instances defined in the module to module.defns.

--show-definition-line-counts

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.

--show-definition-extents

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.

--show-local-type-representations

Write out information about the representations of all types defined in the module being compiled to module.type_repns.

--show-all-type-representations

Write out information about the representations of all types visible in the module being compiled to module.type_repns.

--show-dependency-graph

Write out the dependency graph to module.dependency_graph.

--imports-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.

-d stage

--dump-hlds stage

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.

--dump-hlds-options options

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:

‘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

‘L’

restrict the output of type table entries to local types only

‘M’

mode and inst information

‘O’

dependency and dependency ordering 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

--dump-hlds-pred-id predid

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.

--dump-hlds-pred-name name

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-hlds-inst-limit N

Dump at most N insts in each inst table.

--dump-hlds-file-suffix

Append the given suffix to the names of the files created by the ‘--dump-hlds’ option.

--dump-same-hlds

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-mlds 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-mlds-pred-name name

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.

--verbose-dump-mlds stage

Dump the internal compiler representation of the MLDS, after the specified stage number or stage name, to module.mlds_dump.num-name.

--mode-constraints

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.

--simple-mode-constraints

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.

--benchmark-modes

Output information about the performance of the constraint based mode analysis algorithm.

--benchmark-modes-repeat num

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.