Tempo Specializer - Reference manual

Phases

Specialization with Tempo is separated into many phases. They may be grouped into three stages:

  1. Analysis phases,
  2. Compile-time specialization phases,
  3. Run-time specialization phases.

The analysis phases are compulsory. The output of this stage (the action tree) is the shared input of the two independent specialization processes.

Phases Synopsis

The following tables list the successive phases of Tempo, with required input files and generated output files. Only the suffixes of these files are mentioned (see Files). The list of input and output files is exhaustive, apart from this:

  • Each phase reads the config.sml file. However, to keep the table readable, we have listed it only for the first (i.e., Suif parsing) phase.
  • Phases from binding-time analysis to action analysis generate (by default, but this process can be controlled using variable output_mode) an additional file that enables the colored visualization of program annotations. This file is suffixed either with .color (MIME text/enriched format) or .html, depending on the configuration variable viewer (set to emacs by default). It is not listed in the following tables.

Optional input and output files are listed in square brackets [like this], as are optional phase (depending on configuration variables). An optional phase that is not selected, i.e. "run", actually behaves as the identify though it does generate output files.

Analysis Phases

The goal of the analysis phases is to compute specialization actions. An important intermediate stage is the binding-time information, which is split into three steps in Tempo: binding-time analysis and evaluation-time analysis (1 and 2).

 

Synopsis of the Analysis Phases
Input FilesAnalysis PhasesOutput Files
c
config.sml
[actx.c]
 Suif parsing spd
[actx.spd]
spd
[actx.spd]
 Suif abstract syntax generation st
suif.c
[actx.st]
[actx.suif.c]
st
[actx.st]
 Tempo abstract syntax generation as
decl.h
as
 [Early pre-processing] preproc1.as
preproc1.as
 Goto elimination nogoto.as
nogoto.as
 Alias analysis alias.as
alias.as
 Indirect call elimination nofp.as
nofp.as
 Side-effect analysis se.as
se.as
 Binding-time analysis bta.as
bta.as
 Evaluation-time analysis (1) eta1.as
eta1.as
 Evaluation-time analysis (2) eta2.as
eta2.as
 Flattening of static returns flsret.as
flsret.as
 Flattening of Static&Dynamic calls flsd.as
flsd.as
 [Late pre-processing] preproc2.as
preproc2.as
 Action analysis at

Compile-Time Specialization Phases

The goal of the compile-time specialization phases is first to build a dedicated specializer (from the original program and the initial binding-time information), and then to let the user generate many specialized source files for different specialization values.

 

Synopsis of the Compile-Time Specialization Phases
Input Files Compile-Time Specialization Phases Output Files
at
 Compile-time specializer generation ev.c
ctspec.C
sctx.h
ev.c
ctspec.C
sctx.h
sctx.c
 Compile-time specializer compilation ctspec
ctspec
 Compile-time specialization rawcts.as
rawcts.as
 Post-processing postproc.as
postproc.as
 Pretty-printing
& extra code transformations		 cts.c
cts.h
cts.tempo.c

Run-Time Specialization Phases

The goal of the run-time specialization phases is to build a dedicated run-time specializer (from the original program and the initial binding-time information). Specialized versions with respect to execution-time values are generated as pointers to dynamically created functions. The invocation of the run-time specializer is left to the user. Architecture dependent files are created under a subdirectory ARCH named after the current platform. (See also variable arch_dep_dir.)

 

Synopsis of the Run-Time Specialization Phases
Input Files Run-Time Specialization Phases Output Files
at
 Run-time specializer generation gram
rts.h
temp.c
temp.d
rtspec.c
Under ARCH/
rtspec.o
temp.i
temp.o
rts.o
at
 `C specializer generation rtstc.c
rtstc.h

 

Description of the Phases

The original program undergoes several transformations before actually being treated by Tempo. Some are just side-effects of the Suif front-end while most others are aimed at translating full ANSI C into a smaller and easier to handle subset of the language. Tempo's post-processing rebuilds some constructs that are transformed at this stage so that the output looks more like the original source.

Parsing

C pre-processing, parsing, and transformation of the original file(s).

The parsing of the c file relies on Suif's scc. It includes C pre-processor expansion (using cpp) and, optionally, some pre-processing using porky. If the actx.c file exists, it is parsed as well.

The invocation pattern of the parsing phase is as follows.

scc scc_flags -.spd file.c
If the configuration variable porky_flags is not the empty string, the following additional transformation pass is run: 
porky porky_flags file.spd file.porky_spd
mv file.porky_spd file.spd
A similar pattern is applied to the actx.c file, if present.

Suif makes some simplifications of the source program:

  1. When there are several occurrences of the same string in a program, Suif creates a static global variable for the string with the value of the string initialized in the variable declaration. This is common with printf() statements, that often have similar format strings. We have no control over that.
  2. switches with at most 3 cases are rewritten into a cascade of ifs. Note that Tempo does not currently handle switch.
  3. Suif also turns while and for loops into do while loops. This transformation duplicates the condition expression.

In addition, we use an option of Suif (of porky actually, see porky_flags variable) to turn static (in the C sense) variable into global variables.

See also:

Suif abstract syntax generation

Transformation of Suif .spd files (i.e. file.spd and, possibly, file.actx.spd) into a Suif abstract syntax readable by Tempo, i.e. .st files.

It is for internal usage.

Tempo abstract syntax generation

Building of a Tempo abstract syntax tree by merging the original program (in st form) and, if present, the actx.c file (in st form as well).

Tempo makes some simplifications of the source program:

  1. Function variables that are declared in nested blocks are lifted into the main block of the function.
  2. Initializations of global variables (including arrays, structures and unions) are split into a separate declarations and a/some assignment(s). This introduces a new function named init_compound_data() that contains all the assignements. A call to this function is inserted as the first instruction in the body of the entry point. E.g., 
    int x = 3;
    int u[3] = {1,0,5};
    char hip[] = "hop";

    yields

    int x;
    int u[3];
    char hip[4];

    void _init_compound_data_1()
    {
      x = 3;
      u[0] = 1;
      u[1] = 0;
      u[2] = 5;
      strcpy(hip,"hop");
    }

    There is a special case for character arrays: By default, initialization is performed using strcpy() rather than with tons of single assignments (see the explode_compound_data_strings variable).

Note that initialization of compound data (i.e. arrays, structures and unions) for local variables seems to be broken at the Suif level.

See also:

Early pre-processing

Inlining of functions with multiple returns.

This phase is used to get better results for run-time specialization until run-time inlining is implemented. There are actually two preprocessing inlining phases. Inlining functions with multiple returns introduces gotos, which must be eliminated during goto elimination phase. Thus such functions must be inlined before goto elimination. It is not desirable, however, to perform a complete inlining at this point, because this transformation can greatly increase analysis time and make the code less readable. Thus functions with a single return are inlined as late as possible, i.e., in the late pre-processing phase just before the action analysis.

See also:

Goto elimination

All gotos are eliminated by introducing if, while, and break constructs, using temporary variables. The transformation also removes all labels, whether it is the target of a goto or not. This enables Tempo to work internally on a smaller subset of C. It greatly simplifies the subsequent analysis phases.

Alias analysis

Computation of alias annotations, i.e., the set of possible target locations for each pointer dereferencing.

A location is either:

  • a scalar variable (local or global),
  • an array (one single location for all array cells),
  • a structure field (one single location for all instances of this structure type)
Note that there is no implicit location for heap allocated objects. This analysis is:
  • flow-sensitive: alias information depends on program point,
  • not context-sensitive: different calls with different alias information are merged.
  • monovariant with respect to structures --- being able to point to a single structure instance means being able to point to all the instances.

For the analysis to be correct, Tempo has to know all the possible aliases of locations if they have an impact on the program semantics. Alias information computed outside the program fragment to be specialized can be specified using the file.actx.c analysis context file.

See also:


Indirect call elimination (a.k.a. function pointer elimination)

Transformation of all indirect calls into standard calls. For example:

(*fexp)(exp1,exp2)

is rewritten into something like

_apply_37(fexp,exp1,exp2)

The number that follows _apply_ is some (unique) integer. The corresponding function definition is generated automatically; it depends on the possible values for *fexp, as computed by the alias analysis. This function has the following form:

type _apply_37(_q,_a1,_a2)
{
  if (_q == func1)
    return func1(_a1,_a2);
  else if (_q == func2)
    return func2(_a1,_a2);
  else
    return func3(_a1,_a2);
}

supposing the possible targets are func1, func2 and func3.

If the _apply_37 function is totally static or totally dynamic, it is turned back into an indirect call during action analysis; indeed there is not any specialization to perform. Otherwise, if some specialization of functions func1, func2 and func3 is possible, the explicit dispatch stays in the residual program: if there is not too many cases, calling a specialized function should compensate for the ifs.

If the list of possible targets includes some totally unknown function pointer (e.g., provided in a global variable or as an actual argument to the entry point), Tempo may generate something in the form of

type _apply_37(_q,_a1,_a2)
{
  if (_q == func1)
    return func1(_a1,_a2);
  else if (_q == func2)
    return func2(_a1,_a2);
  else if (_q == func3)
    return func3(_a1,_a2);
  else
    return (*_q)(_a1,_a2);
}

The indirect call (*_q)(_a1,_a2) at the bottom of the function assumes that it cannot jump to any of the functions in the program; it is treated as an external call, i.e. evaluated or rebuilt (depending on variable residualize_all_icalls).

See also:

Side-effect analysis

Recording in each function signature the set of non-locals variables that are read or written.

See also:


Binding-time analysis (a.k.a. BTA)

Annotation of the program with binding-time information.

This analysis is:

  • flow-sensitive: binding-time information depends on program point,
  • context-sensitive: different calls with different binding-time contexts yield different function analyses,
  • return-sensitive: there is a separate binding time for the body and the return value of a function
Note that because of the polyvariance (context sensitivity), some functions may appear duplicated due different binding times. Also, notice that sensitivity is limited to scalar values.

The BTA alone does not yield correct binding-time annotations. Evaluation-time analysis is needed, providing the ``use-sensitivity'' feature. When visualizing BTA files, note also that static left-hand side of assignments only means that the address of the location is static, not that the content is static.

See also:


Evaluation-time analysis (1) (a.k.a. ETA 1)

This analysis turns into dynamic all static expressions that appear in a dynamic context and whose corresponding values have no textual representation in C (i.e., pointers, structures and arrays). If such an expressions were to remain static, it would not be possible to provide a textual representation for it in the compile-time specialized program. This constraint might be partly removed in the case of run-time specialization since no textual representation is required (see lift_all, and lift_global variables).

See also:


Evaluation-time analysis (2) (a.k.a. ETA 2)

This analysis implements return sensitivity and completes the binding-time analysis. It turns into dynamic all the static definitions of variables with dynamic uses. If there is no static use of a definition, it is turned totally dynamic as the static facet is not needed. The analysis is also monovariant with respect to structures.

See also:


Flattening of static returns (a.k.a. Flattening 1)

This transformation rewrites functions (both at the call site and the corresponding definition) that contain a dynamic body but static returns.

The transformation consists of two parts:

  • In the function definition:
    1. Replace the return exp statements with an assignment statement to a fresh, new global variable (a.k.a. the return variable).
    2. Turn the return type of the function to void.
  • At the call site:
    1. Insert a statement before the call point that calls the new void function.
    2. Replace the call by the return variable.

Flattening of static & dynamic calls (a.k.a. Flattening 2)

This transformation flattens nested function calls with S&D parameters. There is no fundamental need for it; it just simplifies the action analysis that follows. After the transformation, function calls with S&D parameters can only be in one of these two forms:
  • func(... S&D parameters ...);
  • lexp = func(... S&D parameters ...);

Late pre-processing

Inlining of functions with a single return.

It is used to get better results for run-time specialization until run-time inlining is implemented. The reason why there are two pre-processing inlining phases (the other is the early pre-processing) is that functions with multiple returns introduce gotos, which must be eliminated (see goto elimination). Functions with single return are inlined as late as possible (i.e., just before the action analysis) because pre-inlining can otherwise greatly increase analysis time.

Action analysis
Translation of binding-time information into specialization actions (i.e., atomic transformations). Action analysis also turns explicit switches over functions pointers back into indirect function pointer calls when they are fully static or dynamic (see indirect call elimination).

Compile-time specializer generation
Separation of static code fragments (to be evaluated) from the actions (driving of specialization and code reconstruction) to be performed by the compile-time specializer.

Compile-time specializer compilation

Compilation and linking of all the files needed for compile-time specialization:
  • an action tree to be interpreted (file ctspec.o),
  • the generic action interpreter (library file libctcg.a),
  • static fragments to be computed (file ev.o),
  • a function setting the initial specialization context (file sctx.o),
  • possibly, user libraries (see variable ctcg_ldlibs).

See also:

Compile-time specialization
Execution of the compile-time specializer. By default, the compile-time specializer expects non-recursive programs.

See also:

Post-processing
Some transformations on the specialized program, not related to specialization.
  • Optimizations:
    • Inlining,
    • Algebraic simplifications.
  • Clean-up:
    • Dead-code elimination,
    • Removal of empty blocks and uselessly nested blocks
  • Re-sugaring.

See also:

Pretty-printing
Additional porky post-processing

Generation of the resulting compile-time specialized program in C text format.

An optional, additional post-processing transformation using porky may be performed. For example, porky can be used to perform some copy propagation on the specialized program. The invocation pattern of porky is as follows.

scc -.spd file.cts.c file.cts.spd
porky post_porky_flags file.cts.spd file.cts.porky_spd
cp file.cts.c file.tempo.c
s2c post_s2c_flags file.cts.porky_spd file.cts.c
As may be seen above, the original Tempo specialization is kept in file file.tempo.c.

See also:

  • porky (assorted code transformations)

Run-time specializer generation

Generation of the run-time specializer. The generated rts.o file is to be linked to the original application in order to generate specialized programs at execution time. The name of the function to call to do so (i.e., the dedicated specializer) is in the rts.h header file.
See also:

`C specializer generation

Generation of a run-time specializer as `C (i.e., tick C) input file.

Note that this functionality is unstable.

Files

Tempo operates on files that are all in the same directory (or in an architecture-dependent sub-directory). Furthermore, they all share the same file name prefix. For example, if the program to specialize is /home/jake/spec/power.c, all files are read and generated in the directory /home/jake/spec/. Starting from the file power.c, Tempo also reads power.config.sml and generates, e.g., power.at and power.cts.c.

Tempo File Suffixes

Below is the list of all Tempo file suffixes and their description.

actx.c
Abstract functions for modeling:
  • the context of the program before the entry point is called,
  • external functions called in the program,
  • the context of the program after the entry point is called.
It is a legal C file, optionally provided by the user.
See also:
actx.spd
Suif internal format for the actx.c file abstract syntax.
This is an intermediate file, hidden by default to the user. It is not generally useful unless the user is wondering what exactly Suif has done to his file.
See also:
actx.st
Textual tree representation for the Suif abstract syntax of the actx.c file.
It is an intermediate file, hidden by default to the user. It is not generally useful to the user.
See also:
actx.suif.c
C text format of the Suif representation for the actx.c file.
It is an intermediate file. It enables one to check whether Suif performed any (generally minor) transformation to the original program.
See also:
alias.as
Program annotated with alias information, i.e., set of possible target locations for each pointer dereference.
It is an intermediate file, hidden by default to the user.
See also:
as
Tempo abstract syntax for the merging of the original program and, possibly, the actx.c file.
It is an intermediate file, hidden by default to the user.
See also:
at
at.color
at.html
Program annotated with actions.
This generated file is the final result of all the analysis phases. The color (or html) file shows a program annotated with actions represented as colors. If the user is not satisfied with the degree of specialization, or would like to better understand the stages of the analysis that led to those action annotations, the color files associated with the bta or eta2 can be helpful.
See also:
bta.as
bta.color
bta.html
Program annotated with binding-time values.
Note that some functions may appear duplicated due to polyvariance.
See also:
c
Original C source of the program to specialize.
This file must be provided by the user.
See also:
config.sml
Configuration and information for analysis and specialization.
This file must be provided by the user. It is a legal SML file. It is read before running any Tempo phase. It is used to define program-specific variables. In particular, the definition of the SML variable entry_point is required. Here is an example:
entry_point := "foo(S,D)";
static_locations := ["u","v","str.a"];
external_functions := EVALUATE(["bar"]);
post_inlining := true ;
post_inlining_mode := FLAT;

See also:

cts.c
cts.h
cts.tempo.c
Compile-time specialized program.
The cts.c file is the final result of compile-time specialization. The cts.h file is used to reduce the size of the cts.c file, in case there are many declarations.
This file is overwritten if, after compile-time specialization, an additional post-processing phase is requested. In that case, the result of the original specialization is saved with the name cts.tempo.c.
See also:
ctspec
An executable form of a compile-time specializer; it consists of
  • an action tree to be interpreted (file ctspec.o),
  • the generic action interpreter (library file libctcg.a),
  • static fragments to be computed (file ev.o),
  • a function setting the initial specialization context (file sctx.o),
  • possibly, user libraries (see variable ctcg_ldlibs).
See also:
ctspec.C
Actions to be performed by the compile-time specializer.
This is a C++ file (because the compile-time specializer, i.e., the action interpreter, is written in C++). It contains all the dynamic fragments (in abstract syntax form) to rebuild; names of functions to call to evaluate static expressions (found in file ev.c); and, the actions to perform.
See also:
decl.h
Type and global variable declarations found in the program.
Sometimes programs have numerous of declarations because many header files are included. Parsing inlines all the include directives. In order not to obscure the visualization of analyzed files, when the global declarations are to numerous, they are all removed and replaced by the include directive referring to decl.h.
See also:
eta1.as
eta1.color
eta1.html
Program where some static expressions have been turned into dynamic expressions because they occur in a dynamic context and do not correspond to representable values (i.e., pointers, structures and arrays).
See also:
eta2.as
eta2.color
eta2.html
Program where static definitions of variables with dynamic uses have been turned static and dynamic, or dynamic only if those variables have no static use.
Note that some functions may get duplicated due to polyvariance.
See also:
ev.c
Code fragments to be evaluated during compile-time specialization.
See also:
flsret.as
flsret.color
flsret.html
Program where functions with a dynamic body and static returns have been rewritten as void functions performing a side effect on a fresh ``return variable''.
The corresponding transformation makes explicit the return sensitivity. It simplifies the specialization actions.
See also:
flsd.as
flsd.color
flsd.html
Program with flat static & dynamic calls.
The corresponding transformation just simplifies the specialization actions.
See also:
gram
Grammar representing all possible specializations of the program.
This file is generated for information only. See also:
nofp.as
Program with function pointers turned into explicit calls.
The corresponding transformation enables Tempo to work on a smaller subset of C. The switches that make calls explicit are turned back into indirect function pointer calls during the action analysis.
See also:
nogoto.as
Program with gotos turned into conditionals and loops.
The corresponding transformation enables Tempo to work on a smaller and structured subset of C.
See also:
postproc.as
Post-processed specialized program.
The corresponding transformation does some code clean-up, some simple optimizations not related to specialization, and some re-sugaring.
See also:
preproc1.as
preproc1.c
Program with early pre-processing.
The corresponding transformation performs inlining of functions with multiple returns. It is used to get better results for run-time specialization, until run-time inlining is implemented.
See also:
preproc2.as
preproc2.color
preproc2.html
Program with late pre-processing.
The corresponding transformation performs inlining of functions with single returns. It is used to get better results for run-time specialization, until run-time inlining is implemented.
See also:
rawcts.as
rawcts.c
Raw output of the compile-time specializer.
By default, only the rawcts.as file is generated. Use the variable output_mode or command as2c to visualize the C text version of this file.
See also:
rts.h
rts.o
Run-time specializer.
The generated rts.o file is the final result of the run-time specialization phase. The user may link it with his original application in order to generate specialized programs at execution time. The name of the function to call to do so (i.e., the dedicated specializer) is in the rts.h header file.
See also:
rtspec.c
rtspec.o
Generating extension (i.e., template assembler and hole filler).
The function defined in this file assembles pre-compiled templates (i.e., the dynamic slice of the code) according to the specialization actions. It also plugs into the templates the result of evaluating the static expressions.
See also:
rtstc.c
rtstc.h
Run-time specializer as a `C input file.

Note that this functionality is unstable
See also:

sctx.c
Compile-time specialization context.
This is a legal C file that must be provided by the user. It must contain the definition of a function named set_specialization_context(). This function initializes globals and entry-point parameters declared as static at the analysis phase.
See also:
sctx.h
Header file for the compile-time specialization context. This file is automatically generated. Do not attempt to edit it. It makes the connection between the store (file ev.c) and the setting of the specialization context (file sctx.c).
See also:
se.as
Program with side-effect annotations. The corresponding transformation records in each function signature the set of non-local variables that are read or written.
See also:
spd
Suif internal format for the c file abstract syntax.
This is an intermediate file, hidden by default to the user. It is not generally useful unless the user is wondering what exactly Suif has done to his file.
See also:
st
Textual tree representation for the Suif abstract syntax of the c file.
It is an intermediate file, hidden by default. It is not generally useful to the user.
See also:
suif.c
C text format of the Suif representation for the c file.
It is an intermediate file. The user may check whether Suif performed any (generally minor) transformation to the original program.
See also:
temp.c
temp.o
Code templates for run-time specialization.
This file contains the templates that represent the dynamic operations of the code to specialize at run time.
See also:
temp.d
Symbolic description of the template holes used for run-time specialization.
This file lists each template name of the program to specialize and the symbolic address of its holes.
This intermediate file is hidden by default to the user. It is the input of the tcc template compiler, together with the temp.o file. The output of tcc is the temp.i file.
See also:
temp.i
Physical description of the template holes used for run-time specialization.
This file lists each template name of the program to specialize and the relative address of its holes.
This intermediate file is hidden by default to the user. It is the output of tcc, that makes explicit the symbolic description of code templates found in the temp.d file.
See also:

Tempo File types

Here is the list of all file types manipulated by Tempo.

.as
Concise form of the abstract syntax used by Tempo to represent programs. It includes alias, side-effect, and binding-time information.
.at
Concise form of the abstract syntax used by Tempo to represent action-annotated programs.
.C
C++ file.
.c
C file.
.color
MIME text/enriched format of annotations on a program. It can be viewed using emacs' enriched mode. (See the variable viewer.)
.d
Symbolic description of code templates for run-time specialization.
.gram
Grammar representing all possible specializations of a program.
.H
C++ header file.
.h
C header file.
.html
HTML representation of the annotations of a program. (See variable viewer.)
.i
Physical description of code templates for run-time specialization.
.o
Object file obtained by compilation of a C or C++ file.
.sml
SML file. (Most parts of Tempo are implemented in SML but the only SML files that the user should ever see are the config.sml and the .tempo.sml files).
.spd
Suif internal abstract syntax representation of a program.
.st
Tempo representation of the Suif abstract syntax for a program.

Other Files

Here are other files (not suffixes) relevant to Tempo.

.tempo.sml
If the user has a .tempo.sml file in his home directory (that is the full name, not just an file extension), it is loaded when tempo (the Shell command, not the SML function) is run. This enables the user to customize standard settings. The file is loaded only once.
See also:

Commands

In the Tempo environment, there are two kinds of commands

:

The Tempo SML top-level commands are the most commonly used in practice. We consider each kind in turn.

Shell-Level Commands

All the shell-level commands that follow are available in the Tempo distribution for any of supported platforms. In practice, the user only needs to run the tempo command; all other commands are implicitly run from the Tempo top-level.

tempo
Run the Tempo Top Level. This is interactive SML top level where all of the Tempo functionalities have been pre-loaded. When it is started, the user should see something that looks like this (the output of the system is in bold face): 
mingus% tempo
Running Tempo on SunOS-5
TEMPO Version 1.191, 03/24/98, Copyright (c) IRISA/INRIA-Universite de Rennes
val it = () : unit
-

The architecture name is that of the current machine. The version number and creation date depend on when Tempo was built (not when it was installed). The ``-'' sign is the prompt character.

See also:

porky
snoot
s2c
s2st
scc
See the Suif manual page

Tempo Top-Level Commands

Here are the Tempo commands that the user can type at the Tempo SML top-level.

See also:

an file
Running analyses. Starting from file.c, run all the analysis phases and generate a file.at file. The string argument file must be a name without any path or extension, e.g., "power".
Example:
an "power";
Note that this is actually an abbreviation for: tempo file "c" "at".
as2c file.as
Generation of C text from abstract syntax format. This command reads file.as, which must be a valid Tempo abstract syntax file (see the suffix ``.as''), and writes it in C text format into file.c. The string argument must be a name with the ``.as'' extension, e.g., "power.bta.as".
Example:
as2c "power.rawcts.as"; (* generate power.rawcts.c *)
cd directory
Changing working directory. Tempo operates on files that are all in the same directory (or in an architecture-dependent sub-directory). This command changes the working directory of Tempo. It also changes the current working directory (in the shell sense) of the SML top-level. (This could have an impact in case of explicit I/O.) The string argument directory may be absolute or relative. The working directory may also be changed using the SML variable wd.
Example:
cd "/home/jake/spec/power/";
cd "../rpc";
cs file
Generation of compile-time specializer. Tempo operates on files that are all in the same directory (or in an architecture-dependent sub-directory). Starting from the action file file.at, this command generates the compile-time specializer file.ctspec.C. The string argument file must be a name without any path or extension, e.g., "power".

Example:
cs "power";
Note that this is actually an abbreviation for: tempo file "at" "ctspec".
freeze_points file
Listing of static locations turned dynamic. This command analyses file.bta.as for variables/fields declared to be static in file.config.sml which are ``frozen'' (i.e., which become dynamic) and print the function in which they become dynamic. This can be some help in ``debugging'' BTA results in large files.
Warning: static assignments under dynamic control cause the variable/field to become dynamic in the function containing the dynamic control, not the function containing the assignment.
Example:
freeze_points "power";
See also:
  • Command tempo (to generate file.bta.as)
  • Variable output_mode (to dump file.bta.as)
print_config file
Printing of configuration variables. Command print_config returns (and displays) the values of Tempo configuration variables. If the string argument file is the empty string, then the current state is returned. If file is not empty, it must be a name without any path or extension, e.g., "power"; it then returns the configuration that would be used when loading the file.config.sml file.
Example:
print_config "";
print_config "power";
rs file
Generation of a run-time specializer. Starting from the action file file.at, command rs generates the run-time specializer file.rts.o. The string argument file must be a name without any path or extension, e.g., "power".
Example:
rs "power";
Note that this is actually an abbreviation for: tempo file "at" "rts.o".
sp file
Performing specialization. Starting from the specializer file.ctspec.C, command sp generates the compile-time specialized program file.cts.c. The string argument file must be a name without any path or extension, e.g., "power".
Example:
sp "power";
Note that this is actually an abbreviation for: tempo file "ctspec.C" "cts".
tempo file start_extension end_extension
Running phases. Starting from file.start_extension, command tempo runs all the required phases to produce file.end_extension. The string argument file must be a name without any path or extension, e.g., "power". The start_extension and end_extension strings may qualify an actual file without mentioning a specific type extension, e.g., "bta" (same as "bta.as"), "at".
Example:
tempo "power" "bta" "at";
tempo "power" "at" "cts";

Variables

Tempo can be configured with two kinds of user variables:

As is the case for commands, the SML variables are the most commonly used in practice. We consider each kind in turn.

Shell-Level Variables

In the following description of variables, we denote by $TEMPOHOME the installation directory of Tempo, even though such a Shell variable is not visible to the user. The user does not have to know this directory (apart from the need to run the tempo command) as the other paths are relative to this one.

TEMPOWORK (default: "")
Starting working directory. This Shell variable controls the initializing of the Tempo working directory. If the string is empty (the default), the starting working directory is the directory where the tempo Shell command is invoked. If the string is not empty, the working directory is initialized to the directory specified by the string.

See also:

  • Command: cd
  • Variable: wd
TEMPOSUIFHOME (default: "")
Tempo-Suif main directory. This variable can be used to override the default setting of Suif variable SUIFHOME (performed by the tempo shell-level command) in order to run Suif commands other than those provided with Tempo. (You will most likely never need to do this.) Be careful though that the s2st command will not be found outside of the distribution of Tempo.

See also:

  • Suif Variable: SUIFHOME (Suif main directory)
  • Suif Command: s2st (Suif abstract syntax printer)

See also:

  • Suif Variable: MACHINE (target architecture)
  • Suif Variable: SUIFHOME (Suif main directory)
  • Suif Variable: SUIFPATH (Suif path to binaries)

Tempo SML Top-Level Variables

The following SML variables may be set at the SML top-level or in the SML files. A few of them are still undocumented. Some names may seem strange; this is for historical reasons...

See also:

arch_dep_dir (default: "current platform architecture")
Directory for RT architecture dependent files. Architecture-dependent files generated during run-time specialization phases are stored in a sub-directory of the current working directory that is named after this variable. The default value is set when the session is open, depending on the platform architecture on which Tempo is running. Possible default values are the same as for variable architecture.
architecture (default: "current platform architecture")
Current architecture. This variables stores, for internal purposes, the name of the platform architecture on which Tempo is running. It should not be altered by the user. Possible values are:
"SunOS-4"
Sun OS 4.1
"SunOS-5"
Sun OS 5.5, i.e., Solaris 2.5
"Linux-2"
Linux on PC
compiler (default: "")
C Compiler for compile-time and run-time specialization. This variable specifies which compiler to use to compile the compile-time specializer and the template binaries. The default value "" means that gcc will be used.

See also:

csd (default: "$TEMPOHOME/ctcg")
Compile-time specializer internal directory. This is the path to the compile-time specializer internals (library and header files). In practice, it should not be altered by the user.
ctcg_cflags (default: "")
ctcg_ldflags (default: "")
ctcg_ldlibs (default: "")
Compilation flags for the CT specializer. Those string variables allow additional flags to be passed to the compilation of the compile-time specializer:
  • ctcg_cflags is given to the compiler when compiling CT specializer files, i.e., file.ctspec.C, file.ev.C, file.sctx.c.
  • ctcg_ldflags is given to the linker when linking the above files (together with the specializer library libctcg.a), e.g., "-L/home/jake/lib".
  • ctcg_ldlibs is given to the linker to specify additional libraries, e.g., "foo.o /home/bob/lib/bar.o -lsupermath". Note that the object files, if any, must be specified before any libraries.

See also:

cts_flags (default: "")
Flags for the CT specializer. This variables is given on the command line that calls the compile-time specializer. Known flags of the CT specializer are:
-norec
Tells the CT specializer that the program does not contains recursive calls, enabling a faster code generation.

Note that the -norec option is unsafe.

default_cts_bufsize (default: 5M)
Buffer size for the CT specializer. This integer variable specifies the size in bytes of the buffer used by the compile-time specializer to store the specialized functions. The value of this variable cannot be assigned by the user.
dummy_entry_point_name (default:"dummy_entry_point")
Name for dummy entry point. This variable provides the name for the dummy entry point, which is created when there exist a set_specialization_context() or a set_post_analysis_context() function in the .actx.c file.
entry_point (no default value)
Specialization entry-point. This variable specifies both the function entry point in a program (i.e., the original C file) and the binding times of its arguments. The value is a string that mimics the entry point function call, e.g., "power(D,S)". Possible values are function(arguments) where arguments is a (possibly empty) list of the following items:
S
Static argument.
D
Dynamic argument.
_
Undefined or composite (i.e., non-scalar) argument.

An error is reported if the number of arguments of function specified by the variable entry_point is not the same as the number of arguments of the actual function in the program.

For the time being, Tempo is restricted to a single entry point and binding-time information definition.

Note that there is no default value for this variable. Not only must it be defined explicitly by the user, but also the definition must appear in the config.sml file. Setting it at the top-level has no effect. This restriction is to prevent unwanted ``side-effects'' when specializing several programs in the same Tempo session.

See also:

explicit_cts_bufsize (default: NONE)
Buffer size for the CT specializer. At the moment, the compile-time specializer requires the size of the specialization buffer to be specified. The explicit_cts_bufsize enables the user to override the default buffer size. Possible values are:
NONE
The default buffer size value is used. The current default value is given by the SML variable default_cts_bufsize. (Note that, unlike other Tempo SML variable, the user cannot modify this variable as its value is not a reference.) The current default size is 5M, i.e., 5000 * 1024 bytes.
SOME size
The specified integer size (in bytes) is used.
explode_compound_data_strings (default: false)
String initialization control. The C subset treated by Tempo does not include initializations. As a result, Tempo rebuilds explicit assignments for all initializations, including compound data. As a string is seen as an array of characters, one explicit assignment is introduced for each array cell, i.e., each character in the string. This variable permits such initializations to be performed in one single statement using C function strcpy(). For example, the following initialization: 
char my_array[3] = "hi";
is rewritten as 
char my_array[3];
my_array[0] = 'h';
my_array[1] = 'i';
my_array[2] = '\0';

when explode_compound_data_strings is true.

Initializations are in this more compact form 
char my_array[3];
strcpy(my_array,"hi");
when explode_compound_data_strings is false. Note that this variable does not affect other kinds of compound data initializations.
external_functions (default: EVALUATE[])
Binding time of external functions. This variable specifies whether external functions should be evaluated if possible (i.e., all arguments are static) at specialization time or should always be residualized (regardless of the arguments). In practice, the former case is often used for calling library functions and the latter for preventing I/O side-effects at specialization time (such as printing). Possible values are:
EVALUATE [functions]
All external functions whose name appears in the string list functions can be called at specialization time if their arguments are available (i.e., static). The other external functions are considered dynamic and are always residualized. In particular, EVALUATE[] forces the residualization of all external functions.
RESIDUALIZE [functions]
All external functions whose name appears in the string list functions are always residualized. The other external functions can be called at specialization time if their arguments are available (i.e., static). In particular, RESIDUALIZE[] enables all external functions of the program to be called at specialization time, when possible.

See also:

 

extra_rts (default: false)
Size of run-time specialized functions. This is an UNSTABLE feature. When this variable is true, building a run-time specializer generates an extra function. This functions returns the size of a specialized function (it has the same interface as the run-time specializer generated along) instead of a pointer to it. This only used to satisfy curiosity and fill tables in papers.

The funny things are that you have to set arch_dep_dir to ".", and that the generated files are named file.rts.sh and file.rts.so.

 

gnumake (default: machine dependent)
Path for gnu tools. This is an internal variable, set via the tempo shell-level command, that need not be altered by the user.

 

keep_headers (default: true)
Controlling whether information about read/written/etc. variables is included in the at file. When this variable is true, the information about read/written/etc. variables is kept in the at file. When this variable is false, this information is removed. Note that this flag is different than verbose_headers, which only affects the color files, although if there is no such information in the at file, it won't appear in the at.color file either, regardless of the value of verbose_headers. Setting this flag to false is useful to cut down the size of the at file, either to save disk space or to make it quicker to read by the cs and rs commands.

 

lift_all (default: false)
Controlling the lifting of pointer values for run-time specialization.
true
The ETA allows all pointer values to be lifted.
false
The ETA disallows pointer values to be lifted.

 

lift_global (default: false)
Controlling the lifting of global pointer values.
true
Setting variable lift_global to true only causes pointers to globals to be lifted. This kind of pointer values represents a safe set of pointer values to lift.
false
It disallows pointers to globals to be lifted.
live_locations (default: [])
Definition of the locations which are live after the end of the program.

Live locations refer to locations that are live at the end of the program being specialized. This can happen during modular-oriented specialization, when the program is extracted from a larger program and then reinserted after specialization.

The variable is a list of strings (location names). A location may be:

  • A global scalar variable, e.g., "foo".
  • A structure field. The notation is then structure_type.field, e.g., point.x where point is the name of a structure type (as given by the declaration struct point {...}), not an instance of that type. This restriction is due to the monovariance of the BTA on structures.

See also:

  • Variable static_locations (syntax and restrictions on locations)
  • File actx.c (fine analysis context description)
  • User manual

 

max_decls_size (default: 100)
Threshold for declarations ellipsis. If the number of global declarations (for types, variables and functions), at the beginning of the file is greater than the integer max_decls_size, then the declarations are hidden in all intermediate C files generated by Tempo (even color files) and can be found in a separate file suffixed by .decl.h. The declarations are replaced by an explanation comment and an include directive.

Similarly, for the compile-time specialized file .cts.c, if there are more declarations than the limit specified by max_decl_size, the declarations are put in a file suffixed by .cts.h and replaced by an include directive.

max_width (default: 78)
Maximum width of the line for printing code. This variable is used for line wrapping when pretty-printing C code.
memoize_aliases (default: true)
Aliases memoized. This variable tells whether alias analysis results should be memoized at call sites. Experiments on some large files have shown that the alias analysis can be much faster with memoization (from more than 3 hours down to a quarter of an hour).

This flag is for internal purposes.

See also:

 

minimize_holes (default: false)
The number of holes in the run-time specialized program is minimized. A static variable in a dynamic context does not lead to any performance improvement from run-time specialization. A hole is generated for such a term. It can be useful to minimize the number of such holes to promote reuse of values stored in registers in the run-time specialized code.
true
Number of holes is minimized.
false
Number of holes is not minimized.
output_mode (default: COLOR)
Control of the intermediate files to generate. This variable specifies which intermediate files to generate when running Tempo phases. Possible values are:
CONCISE
No (unnecessary) intermediate files are generated.
COLOR
Only colored intermediate files are generated (see the variable viewer).
FULL
All intermediate files are generated.
FILES suffixes
Generation of files limited to the target of the last phase and the files specified by their suffixes in the string list suffixes, e.g., FILES ["eta2.color","rawcts.c"].
override_remove_compound_data (default: false)
Remove residualized compound data assignments.
porky_flags (default: "-unused-types -ucf-opt -for-bound -no-index-mod -no-empty-fors -no-empty-table -control-simp -fold -globalize")
Flags for porky. This string variable permits additional flags to be passed on to porky when updating spd files just after parsing. The invocation pattern of porky is as follows.
porky porky_flags file.spd file.porky_spd
In case the value of the variable is altered, the user must make sure to keep the -globalize flag as it turns static variables (in the C sense, i.e., local variables that retain their value between successive function calls) into global variables; the C subset treated by Tempo does not handle such static variables.

See also:

post_clean_up (default: true)
Clean-up in post-processing is enabled. This variable tells whether clean-up should be performed during the post-processing, i.e.,
  • Removal of unused labels,
  • Removal of empty blocks and lines,
  • Flattening of simply nested blocks.
post_common_subexpression (default: true)
Unfolding of expressions in consecutive assignments in post-processing.. This variable tells whether unfolding of expressions in consecutive assignments should be performed during the post-processing, i.e., whether a piece of code :
    x1 = e1;
    x2 = e2; /* x1 occurs in e2 */
should be turned into :
x2 = e2[x1 <- e1];
warning : this transformation can be performed only if the clean up flag is activated.
post_dead_code (default: true)
Dead-code elimination in the post-processing. This variable tells whether dead-code elimination should be performed during the post-processing. Because dead-code elimination is quite buggy at the moment, this is turned off by default.
post_do_inline (default: [])
Inlining in post-processing is forced. This variable holds a list of strings corresponding to function names. If inlining is enabled, it is performed (at least) on all these functions, regardless of other inlining filter flags.

See also:

post_do_not_inline (default: [])
Inlining in post-processing is prevented. This variable holds a list of strings that are function names. Even if inlining is enabled, it is never performed on all those functions, regardless of other inlining filter flags.

See also:

post_inlining (default: false)
Inlining in post-processing is enabled. This variable tells whether inlining should be performed. (Functions returning a value are currently not inlined). Whether inlining of a given call actually takes place also depends on the total number of calls to this function and the size of its body.

See also:

post_inlining_max_nb_calls (default: 5)
Number of calls threshold for inlining. If the number of calls to a function is greater than this variable, then the function is not inlined.

See also:

post_inlining_max_nb_stmts (default: 25)
Body size threshold for inlining. If the number of statements in the body of a function is greater than this variable, then the function is not inlined.

See also:

post_inlining_mode (default: BLOCK)
Style of inlining. This variable specifies the ``style'' of inlining. Possible values are:
BLOCK
Inline functions as blocks: the body structure of the inlined function is retained.
FLAT
Inlined functions are flattened: the body of the inlined function is merged into the list of the statements of the calling procedure.

See also:

  • Inlining (User manual)
post_inlining_renaming (default: true)
Renaming of the parameters of inlined functions. In order to perform inlining, three operations are performed in the calling function.
  • Declarations for the callee formals are inserted.
  • Before the inlined call, assignments are inserted: the formals of the callee are assigned to the actual arguments provided by the caller.
  • The inlined call is replaced by a copy of the body of the callee.
This can cause problem when the formal is of array type, as it is not possible in C to assign an array. (An array is a kind of constant pointer variable).

The possible values of post_inlining_renaming are:

true
Renaming of all the parameters of a function before inlining so that they do not conflict with the actual arguments that are passed.
false
This renaming is not performed.

Note that setting post_inlining_renaming to false can cause bugs. If your program has functions with parameters of pointer type and arguments of array type, the arrays is not referenced correctly once the function is inlined.

This flag is for internal purposes.

See also:

  • Inlining (User manual)
post_porky (default: false)
Additional post-processing after CT specialization. The variable indicates whether, on top of Tempo post-processing, an additional post-processing using porky should be performed. Even if this variable is set to true, no additional post-processing is performed if the variable post_porky_flags is set to the empty string.

See also.

post_porky_flags (default: "-ucf-opt -unused-syms")
post_s2c_flags (default: "-omit-header")
Flags for additional post-processing after CT specialization. Those variables are used to parameterize an extra porky pass after CT specialization, if requested. See the description of the additional porky post-processing phase for the invocation pattern. Common porky options include:

 

-dead-code
Simple dead-code elimination.
-Dblocks
Blocks created from inlining functions are dismantled.
-ucf-opt
Simple optimization on unstructured control flow (branches and labels).
-unused-syms
Removal of symbols that are never referenced and have no external linkage, or that have external linkage but are not defined in this file (i.e., no function body or variable definition).

See also:

post_start_inlining_func (default: [])
Call-graph regions for performing inlining. This variable holds a list of strings which correspond to function names. Inlining is performed only ``below'' those functions in the call-graph. In other words, no inlining is performed on the functions that may eventually call those that are specified in the post_start_inlining_func variable.

In particular, when this list is empty, there are no restriction on where inlining begins. In this case, inlining is allowed everywhere in the call-graph.

Note that this specification is overridden by the effect of the following variables:

post_transform (default: true)
Control over algebraic simplifications during post-processing. If true, some algebraic simplifications are performed during post-processing, e.g. addition to 0, multiplication by 0 or 1, etc.
pre_common_subexpression (default: true)
This variable has the same meaning as the corresponding post-processing variable post_common_subexpression.
pre_do_inline (default: [])
pre_do_not_inline (default: [])
pre_inlining_max_nb_calls (default: 5)
pre_inlining_max_nb_stmts (default: 25)
pre_inlining_mode (default: BLOCK)
pre_inlining_renaming (default: true)
pre_start_inlining_func (default: [])
Pre-inlining variables. Those variables are parameters for pre-inlining occurring during early and late pre-processing. They have the same meaning as the corresponding post-processing variables (starting with a ``post_'' prefix rather than `` pre_'').

See also:

pre_inlining_time (default: NEVER)
Pre-inlining time. The goal of the pre-processing phase is to perform function inlining. It is split into two phases, one early and one late. Each phase can be ignored or forced depending on the variable pre_inlining_time. Possible values are:
NEVER
No inlining performed during either of the pre-processing phases.
EARLY
Inlining limited to the first, early pre-processing phase. All specified functions, whether with a single return or with multiple returns, are inlined.
LATE
Inlining only during the second, late pre-processing phase. Only functions with single returns are inlined in this phase. Functions with multiple returns are not inlined and a warning is issued. This is because the inlining of this kind of functions introduces gotos which cannot be eliminated at this stage.
AUTO
Functions with multiple returns are inlined in the early pre-processing phase and functions with single returns are inlined in the late pre-processing phase.

In most cases, since pre-inlining makes the code less readable, the user wants (in case pre-inlining is really required) to use the AUTO value. This hides pre-inlining as much as possible, i.e., delay it in the course of the analysis phases.

Note that pre-inlining can be useful only when doing run-time specialization. For compile-time specialization, the inlining that occurs during the post-processing is sufficient. When inlining during run-time specialization is implemented, pre-inlining at both pre-processing stages will disappear.

See also:

print_dir_in_html_title (default: false)
Path in HTML title is displayed. This variable specifies whether the full path of the file should be displayed as a title in HTML generated files. Possible values are:
true
The full path, e.g., /home/jake/spec/power.eta2.html is included.
false
Only the name of the file, e.g., power.eta2.html is included.
rebuild_compound_data (default: false)
Reconstruction of initializations. This variables enables the reconstruction of initialized scalar (for the moment) variables during post-processing. This has not much be tested, hence the default value.
reentrant_rts (default: true)
Controlling the allocation strategy of the specialization buffer for run-time specialization. For run-time specialization, the buffer where specialized functions are recorded can either be global or local. In the former case, a unique specialization buffer is used for any specialization; this buffer is allocated statically. As a result, one specialization replaces a previously specialized function. In the latter case, many specialization functions can be used at the same time. A new buffer is thus allocated dynamically each time a specialization is triggered. This feature is essential when the function to specialize is recursive or when multiple specialized versions are needed at a given time. Regardless of the strategy, the run-time specializer always returns the address where the specialized function is stored.

Possible values for this variable are:

true
A new specialization buffer is allocated for each specialization.
false
A unique specialization buffer, statically allocated, is used for any specialization.

Note: Unlike the compile-time specializer, the run-time specializer does not perform a memoization of the functions previously specialized. As a consequence, recursive specialization with previous specialized values cause the specializer not to terminate. For example, backward branches in a byte-code interpreter.

 

remote_target (default: "")
Enabling the compilation of the templates and the run-time specializer to be performed on a remote machine. This variable can be set to a remote machine to define where the compilation of the templates and the run-time specializer should occur. This functionality is typically used to perform the analyses on a fast machine and to run the machine-dependent tasks on the target machine. This is implemented using rsh; the variable should thus be set to a valid machine name.

Note that this facility assumes that there is a shared file system between the machines used.

residualize_all_icalls (default: true)
Binding time of external indirect calls. This variable specifies whether indirect external function calls can be evaluated if possible (i.e., the function pointer and the arguments are static) at specialization time or should always be residualized (independently of arguments). Possible values are:
true
Residualization of all indirect external calls at specialization-time.
false
Evaluation of indirect external calls at specialization-time whenever possible.

See also:

rsd (default: "$TEMPOHOME/rtcg")
Run-time specializer internal directory. This is the path to the run-time specializer internals (library and template compiler). In practice, it should not be altered by the user.
rts_buffer_size (default: 20000)
Size of the specialization buffer for the run-time specializer.

 

rts_compiler_options (default: "-O0")
Setting the compiler options for the run-time specializer. Variable rts_compiler_options defines the compiler options to be used for the compilation of the run-time specializer. Unlike the templates, the run-time specializer can be compiled without any restriction as to the optimization level. Optimizing the run-time specializer mainly impacts the static computations of the program to specialize.

 

s2c_flags (default: "")
Flags for s2c and s2st. This variable can be used to provide options to s2c and s2st when producing file.st and file.st files.

See also:

scc_flags (default: "")
Flags for scc. This string variable allows additional flags to be passed on to scc when parsing C files (program and analysis context) in order to produce spd files. The invocation pattern of scc is as follows.
scc scc_flags -.spd file.c
Typical flags are -Ipath to specify the directory in which to find include files, and -D and -U to specify the values of C preprocessor variables.

See also:

sh_command (default: "")
Shell setting. This string variable represents a command to be put in front of each Shell escape that Tempo runs to perform parsing, compilation, specialization and additional post-processing. It is mainly used to set Shell variables, e.g., 
sh_command := "
  SPE_FLAGS=\"-DSPECIALISATION\";
  CHORUS=/udd/pe/chorus/ClassiX1.1/sr;
  CHORUSFLAGS=\"-DCOMPAQ386 -DKERNEL -DMULTI_IOM
     -I$CHORUS/chorus_3.5\" ";
Common specifications include paths and cpp variable definitions for parsing.
specialized_entry_point_name (default: "")
Name of CT-specialized entry point. The compile-time-specialized entry point function is named after the content of this variable. If it is the empty string, the name of the specialized entry point function will be generated automatically.
static_locations (default: [])
Initial static locations. This variable specifies which locations should initially be treated as static by the BTA analysis (apart from entry point arguments which are specified using variable entry_point). All other locations are assumed dynamic.

The variable is a list of strings (location names). A location may be:

  • A global scalar variable, e.g., "foo".
  • A structure field. The notation is then structure_type.field, e.g., point.x where point is the name of a structure type (as given by the declaration struct point {...}), not of an instance of that type. This restriction is due to the monovariance of the BTA on structures.
Note that, at the moment, it is not possible to use a type name that has been created with the typedef construct. Only the structure name that follows the keyword struct in the declaration of the structure can be used. If there is no name following the keyword struct (an anonymous structure), Suif generates one automatically (named __tmp_structn where n is some number). It is very dangerous to rely on Suif to choose any particular name for this structure. For now, whenever possible, the user is encouraged to modify the source file to give explicit names for such anonymous structures. In any case, an error is reported if the location does not exist.

See also:

struct_polyvariance (default: false)
Structure polyvariance. This variable indicates whether structures should be polyvariant or not, with respect to alias, side-effect and binding-time information, i.e., if the information should be merged for all instances of a given structure type (less precise but faster analysis) or computed for each structure instance (more precise but slower analysis).

Warning: This feature is still experimental and only partly implemented. What you do is at your own ``risk''. Tempo displays which version is chosen (monovariant or polyvariant) as it processes a file.

 

 

templates_compiler_options (default: "-O0")
Setting the compiler options for the templates. Variable templates_compiler_options defines the compiler options to be used for the compilation of the templates used for run-time specialization.

Note that, in our experience, templates can be optimized up to "-O2". Further optimization levels interfere with our template strategy.

 

trim_specialized_func_ids (default: "false")
Trimming of specialized functions names. Specialized functions have funny names like _Gfoo_1_2_3(). When set to true, names look like foo_3().
verbose_aliases (default: true)
Alias information displayed. This variable specifies whether alias information should be included as comments when displaying the program as (possibly colored) C text files. Possible values are:
true
Alias information (possible values for pointer dereference) displayed in generated program text files, i.e., c and colored files (either color or html).
false
This information is omitted.

Example:

get_addr(&a[1])

int get_addr(int *x)
{
  return *x/* a[] */;  /* alias information in comments */
}

Note that alias information is always removed from the cts.C file, unless the verbose_aliases_in_specializations flag is set.

See also:

verbose_aliases_in_specializations (default: false)
Alias information displayed in specialized files. This variable specifies whether alias information should be mentioned when displaying the specialized program as a C text file. The alias information is not generally meaningful as the alias information is not re-computed on the specialized file but only ``inherited'' from the original program via specialization reconstructions. However, some users rely on it to ``guess'' what specialization did. This should not be encouraged; the action file, as well as the BTA and ETA files, contain the right information to predict specialization. Possible values are:
true
Alias information (possible values for pointer dereference) is displayed.
false
This information is omitted.

Note that variable verbose_aliases must be set to true for alias information to be maintained in the specialized program file.

verbose_callsig (default: true)
Polyvariance index is displayed. When displaying program as (possibly colored) C text files, this variable says whether an index should be displayed next to function calls and definitions in order to differentiate between different polyvariant binding-time instances. A function call or definition looks like this: fun/*37*/(arg1,arg2).

Note that both the BTA and the ETA may introduce different polyvariant instances; the resulting index differs from one analysis to the another. In other words, the index is only meaningful for a given file and should not be compared with indices in other files (whether previous or subsequent in the flow of phases). It does not differentiate either between the BTA and the ETA polyvariance: both kinds of polyvariance are ``merged''. Possible values are:

true
Polyvariance index displayed in comment just after a function name at definition and call site.
false
This information is omitted.

See also:

verbose_headers (default: true)
Signature information is displayed. This variable specifies if function signature information should be mentioned when displaying program as (possibly colored) C text files. Possible values are:
true
Signature information is displayed in generated program text files, i.e., c and colored files (either color or html). It includes side-effects of the function with associated binding times, as well as evaluation-time information.
false
This information is omitted.

Example:

int get_addr(int *x) 
/* 
 binding times of read non_locals: a
 residual non-locals in: a
*/
{
  return *x/* a[] */;
}
The signature follows in comments just after the function definition header.

See also:

verbose_rts (default: false)
Verbose generation of run-time specializer. When set to true, prints all the commands that build a run-time specializer.

 

viewer (default: emacs)
Viewer target for colored files. This variable specifies the format (and name) of colored files when displaying program as C text files. Possible values are:
emacs
MIME text/enriched format (see Suffix .color)
html
HTML format (see Suffix .html)
wd (default: ".")
Working directory. Tempo operates on files that are all in the same directory (or in an architecture-dependent sub-directory). This variable contains the path of the current working directory.

See also:

  • Command cd (to change the working directory of the SML top-level as well)
  • Introduction to section on Tempo files
  • Variable arch_dep_dir (sub-directory for architecture-dependent RT files)
 
Tuesday, 02 February 2010 09:00

Inria   LaBRI