Compiler Options

Compiler options can be set in three ways: from a global list of options (see set_global_compiler_options/1), from the compilation command (see compile/2 and consult/2), and from a directive in the file to be compiled (see compiler directive compiler_options/1).

set_global_compiler_options(+OptionsList)

OptionsList is a list of compiler options (described below). Each can optionally be prefixed by + or -, indicating that the option is to be turned on, or off, respectively. (No prefix turns the option on.) This evaluable predicate sets the global compiler options in the way indicated. These options will be used in any subsequent compilation, unless reset by another call to this predicate, or overridden by options provided in the compile invocation, or overridden by options in the file to be compiled.

The following options are currently recognized by the compiler:

optimize

When specified, the compiler tries to optimize the object code. In Version 2.2, this option optimizes predicate calls, among other features, so execution may be considerably faster for recursive loops. However, due to the nature of the optimizations, the user may not be able to trace all calls to predicates in the program. Also the Prolog code should be static. In other words, the user is not allowed to alter the entry point of these compiled predicates by asserting new clauses. As expected, the compilation phase will also be slightly longer. For these reasons, the use of the optimize option may not be suitable for the development phase, but is recommended once the code has been debugged.

xpp_on

Filter the program through a preprocessor before sending it to the XSB compiler. By default (and for the XSB code itself), XSB uses GPP, a preprocessor developed by Denis Auroux (auroux@math.polytechnique.fr) that has high degree of compatibility with the C preprocessor, but is more suitable for Prolog syntax. In this case, the source code can include the usual C preprocessor directives, such as #define, #ifdef, and #include. This option can be specified both as a parameter to compile/2 and as part of the compiler_options/1 directive inside the source file. See Appendix A for more details on GPP.

When an #include "file" statement is encountered, XSB directs GPP preprocessor to search for the files to include in the directories $XSB_DIR/emu and $XSB_DIR/prolog_includes. However, additional directories can be added to this search path by asserting into the predicate xpp_include_dir/1, which should be imported from module parse.

XSB predefines the constant XSB_PROLOG, which can be used for conditional compilation. For instance, you can write portable program to run under XSB and and other prologs that support C-style preprocessing and use conditional compilation to account for the differences:

#ifdef XSB_PROLOG
    XSB-specific stuff
#else
    other Prolog's stuff
#endif
    common stuff

However, as mentioned earlier, XSB lets the user filter programs (except the programs that belong to XSB distribution) through any preprocessor the user wants. To this end, one only needs to assert the appropriate command into the predicate xpp_program, which should be imported from module parse. The command should not include the file name--XSB appends the name of the file to be compiled to the command supplied by the user. For instance, executing

   :- assert(xpp_program('/usr/bin/m4 -E -G')).

before calling the compiler will have the effect that the next XSB program passed to the compiler will be first preprocessed by the M4 macro package. Note that the XSB compiler automatically clears out the xpp_program predicate, so there is no need to tidy up each time. But this also means that if you need to compile several programs with a non-standard preprocessor then you must specify that non-standard preprocessor each time the program is compiled.

auto_table

When specified as a compiler option, the effect is as described in Section 3.8.4. Briefly, a static analysis is made to determine which predicates may loop under Prolog's SLD evaluation. These predicates are compiled as tabled predicates, and SLG evaluation is used instead.

suppl_table

The intention of this option is to direct the system to table for efficiency rather than termination. When specified, the compiler uses tabling to ensure that no predicate will depend on more than three tables or EDB facts (as specified by the declaration edb of Section 3.8.4). The action of suppl_table is independent of that of auto_table, in that a predicate tabled by one will not necessarily be tabled by the other. During compilation, suppl_table occurs after auto_table, and uses table declarations generated by it, if any.

spec_repr

When specified, the compiler performs specialisation of partially instantiated calls by replacing their selected clauses with the representative of these clauses, i.e. it performs folding whenever possible. We note in general, the code replacement operation is not always sound; i.e. there are cases when the original and the residual program are not computationally equivalent. The compiler checks for sufficient (but not necessary) conditions that guarantee computational equivalence. If these conditions are not met, specialisation is not performed for the violating calls.

spec_off

When specified, the compiler does not perform specialisation of partially instantiated calls.

unfold_off

When specified, singleton sets optimisations are not performed during specialisation. This option is necessary in Version 2.2 for the specialisation of table declarations that select only a single chain rule of the predicate.

spec_dump

Generates a module.spec file, containing the result of specialising partially instantiated calls to predicates defined in the module under compilation. The result is in Prolog source code form.

ti_dump

Generates a module.ti file containing the result of applying unification factoring to predicates defined in the module under compilation. The result is in Prolog source code form. See page  for more information on unification factoring.

ti_long_names

Used in conjunction with ti_dump, generates names for predicates created by unification factoring that reflect the clause head factoring done by the transformation.

modeinfer

This option is used to trigger mode analysis. For each module compiled, the mode analyzer creates a module.D file that contains the mode information.

WARNING: Occasionally, the analysis itself may take a long time. As far as we have seen, the analysis times are longer than the rest of the compilation time only when the module contains recursive predicates of arity $\geq 10$. If the analysis takes an unusually long time (say, more than 4 times as long as the rest of the compilation) you may want to abort and restart compilation without modeinfer.

mi_warn

During mode analysis, the .D files corresponding to the imported modules are read in. The option mi_warn is used to generate warning messages if these .D files are outdated -- i.e., older than the last modification time of the source files.

mi_foreign

This option is used only when mode analysis is performed on XSB system modules. This option is needed when analyzing standard and machine in syslib.

sysmod

Mainly used by developers when compiling system modules. If specified, standard predicates (listed in Appendix B) are automatically available for use only if they are primitive predicates (see the file syslib/machine.P for a current listing of such predicates. When compiling in this mode, non primitive standard predicates must be explicitly imported from the appropriate system module.

verbo

Compiles the files (modules) specified in ``verbose'' mode, printing out information about the progress of the compilation of each predicate.

profile

This option is usually used when modifying the XSB compiler. When specified, the compiler prints out information about the time spent in each phase of the compilation process.

asm_dump, compile_off

Generates a textual representation of the SLG-WAM assembly code and writes it into the file module.A where module is the name of the module (file) being compiled.

WARNING: This option was created for compiler debugging and is not intended for general use. There might be cases where compiling a module with these options may cause generation of an incorrect .A and .O file. In such cases, the user can see the SLG-WAM instructions that are generated for a module by compiling the module as usual and then using the -d module.O command-line option of the XSB emulator (see Section 3.5).

index_off

When specified, the compiler does not generate indices for the predicates compiled.