| © 1998 IRISA / INRIA - University of Rennes 1 |
Version |
config.sml file. However, to keep
the table readable, we have listed it only for the first (i.e., Suif
parsing) phase.
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.
| Input Files | Compile-Time Specialization Phases | Output Files |
|---|---|---|
at |
Compile-time specializer generation |
ev.cctspec.Csctx.h |
ev.cctspec.Csctx.hsctx.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.ccts.hcts.tempo.c |
ARCH named after the current platform. (See
also variable arch_dep_dir.)
| Input Files | Run-Time Specialization Phases | Output Files |
|---|---|---|
at |
Run-time specializer generation |
gramrts.htemp.ctemp.drtspec.c |
Under |
||
rtspec.otemp.itemp.orts.o | ||
at |
`C specializer generation |
rtstc.crtstc.h |
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.
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
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
actx.c file, if present.
Suif makes some simplifications of the source program:
printf() statements, that often have similar format
strings. We have no control over that.
switches with at most 3 cases are rewritten into a
cascade of ifs. Note that Tempo does not currently
handle switch.
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:
scc_flags
porky_flags
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.
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:
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:
explode_compound_data_strings (string initialization control)
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:
pre_inlining_time
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.
Computation of alias annotations, i.e., the set of possible target locations for each pointer dereferencing.
A location is either:
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:
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:
residualize_all_icalls
(binding time of external indirect calls)
Recording in each function signature the set of non-locals variables that are read or written.
See also:
Annotation of the program with binding-time information.
This analysis is:
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:
lift_all, and lift_global
variables).
See also:
lift_all
lift_global
minimize_holes
See also:
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:
return exp statements with an
assignment statement to a fresh, new global variable (a.k.a. the
return variable).
void.
func(... S&D parameters ...);
lexp = func(... S&D parameters ...);
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.
ctspec.o),
libctcg.a),
ev.o),
sctx.o),
ctcg_ldlibs).
See also:
ctcg_cflags
ctcg_ldflags
ctcg_ldlibs
See also:
explicit_cts_bufsize
See also:
post_clean_up
(to enable clean-up)
post_common_subexpression
(to enable unfolding of expressions in consecutive assignments)
post_do_inline
(to force inlining of specific functions)
post_do_not_inline
(to prevent inlining of specific functions)
post_inlining
(to enable inlining)
post_inlining_max_nb_calls
(threshold for the number of calls to inline)
post_inlining_max_nb_stmts
(threshold for the body size to inline)
post_inlining_mode
(style of inlining)
post_inlining_renaming
(to rename the parameters)
post_s2c_flags
(flags passed to s2c)
porky post-processing
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
file.tempo.c.
See also:
porky (assorted code transformations)
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.Note that this functionality is unstable.
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.
Below is the list of all Tempo file suffixes and their description.
actx.c
actx.spd
actx.c file abstract syntax.actx.st
actx.c file.actx.suif.c
actx.c file.alias.as
as
actx.c file.at
at.color
at.html
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.
bta.as
bta.color
bta.html
c
config.sml
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
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.cts.tempo.c.max_decls_size)
porky post-processing (producer)
ctspec
ctspec.o),
libctcg.a),
ev.o),
sctx.o),
ctcg_ldlibs).
ctspec.C
ev.c); and, the actions to
perform.decl.h
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.max_decls_size)
eta1.as
eta1.color
eta1.html
eta2.as
eta2.color
eta2.html
ev.c
flsret.as
flsret.color
flsret.html
flsd.as
flsd.color
flsd.html
gram
nofp.as
nogoto.as
postproc.as
preproc1.as
preproc1.c
preproc2.as
preproc2.color
preproc2.html
rawcts.as
rawcts.c
rawcts.as file is generated. Use
the variable output_mode
or command as2c to visualize the C
text version of this file.rts.h
rts.o
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.rtspec.c
rtspec.o
rtstc.c
rtstc.h
Note that this functionality is unstable
See also:
sctx.c
set_specialization_context(). This function initializes
globals and entry-point parameters declared as static at the
analysis phase.sctx.h
ev.c) and the setting of the
specialization context (file sctx.c).se.as
spd
c file
abstract syntax.st
c file.suif.c
c file.temp.c
temp.o
temp.d
tcc template compiler, together
with the temp.o file. The
output of tcc is the temp.i file.temp.i
tcc, that makes explicit the symbolic
description of code templates found in the temp.d file..as
.at
.C
.c
.color
viewer.)
.d
.gram
.H
.h
.html
viewer.)
.i
.o
.sml
config.sml and the .tempo.sml files).
.spd
.st
.tempo.sml
.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. file.config.sml
(per-program configuration file)
tempo command; all other commands
are implicitly run from the Tempo
top-level.
tempo
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 also:
tempo (for
running the system)
an file
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".
an "power";
tempo file "c" "at".
as2c file.as
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".
as2c "power.rawcts.as"; (* generate power.rawcts.c *)
cd directory
directory may be absolute or relative. The
working directory may also be changed using the SML variable wd.
cd "/home/jake/spec/power/";
cd "../rpc";
cs 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".cs "power";
tempo file "at" "ctspec".
freeze_points file
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.freeze_points "power";
tempo
(to generate file.bta.as)
output_mode
(to dump file.bta.as)
print_config file
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.
print_config "";
print_config "power";
rs 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".
rs "power";
tempo file "at" "rts.o".
sp file
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".
sp "power";
tempo file "ctspec.C" "cts".
tempo file start_extension end_extension
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".
tempo "power" "bta" "at";
tempo "power" "at" "cts";
$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: "")
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:
TEMPOSUIFHOME
(default: "")
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:
MACHINE
(target architecture)
SUIFHOME
(Suif main directory)
SUIFPATH
(Suif path to binaries)
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")
architecture.
architecture
(default: "current platform architecture")
"SunOS-4"
"SunOS-5"
"Linux-2"
compiler
(default: "")
"" means that gcc will be used.
See also:
csd
(default: "$TEMPOHOME/ctcg")
ctcg_cflags
(default: "")
ctcg_ldflags
(default: "")
ctcg_ldlibs
(default: "")
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: "")
-norec
Note that the -norec option is unsafe.
default_cts_bufsize
(default: 5M)
dummy_entry_point_name
(default:"dummy_entry_point")
set_specialization_context()
or a set_post_analysis_context() function in the .actx.c file.
entry_point
(no default value)
"power(D,S)".
Possible values are function(arguments)
where arguments is a (possibly empty) list of
the following items:
S
D
_
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:
actx.c
(more precise binding times)
explicit_cts_bufsize
(default: NONE)
explicit_cts_bufsize enables the user to override the
default buffer size.
Possible values are:
NONE
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
size (in bytes) is used.
explode_compound_data_strings
(default: false)
strcpy().
For example, the following initialization:
char my_array[3] = "hi";
char my_array[3]; my_array[0] = 'h'; my_array[1] = 'i'; my_array[2] = '\0';
when explode_compound_data_strings is true.
char my_array[3]; strcpy(my_array,"hi");
explode_compound_data_strings is false. Note that
this variable does not affect other kinds of compound data initializations.
external_functions
(default: EVALUATE[])
EVALUATE [functions]
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]
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:
actx.c
(abstract description of the behavior of external functions)
residualize_all_icalls
(binding time of external indirect calls)
extra_rts
(default: false)
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)
tempo shell-level command, that need not
be altered by the user.
keep_headers
(default: true)
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)
true
false
lift_global
(default: false)
true
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
live_locations
(default: [])
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:
"foo".
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:
static_locations
(syntax and restrictions on locations)
actx.c
(fine analysis context description)
max_decls_size
(default: 100)
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)
memoize_aliases
(default: true)
This flag is for internal purposes.
See also:
minimize_holes
(default: false)
true
false
output_mode
(default: COLOR)
CONCISE
COLOR
viewer).
FULL
FILES suffixes
suffixes, e.g., FILES
["eta2.color","rawcts.c"].
override_remove_compound_data
(default: false)
porky_flags
(default: "-unused-types -ucf-opt -for-bound -no-index-mod -no-empty-fors -no-empty-table -control-simp -fold -globalize")
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
-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:
porky
scc_flags
post_clean_up
(default: true)
post_common_subexpression
(default: true)
post_dead_code
(default: true)
post_do_inline
(default: [])
See also:
post_inlining
(to enable inlining)
post_do_not_inline
(default: [])
See also:
post_inlining
(to enable inlining)
post_inlining
(default: false)
See also:
post_inlining_max_nb_calls
(threshold for the number of calls)
post_inlining_max_nb_stmts
(threshold for the body size)
post_inlining_max_nb_calls
(default: 5)
See also:
post_inlining
(to enable inlining)
post_inlining_max_nb_stmts
(default: 25)
See also:
post_inlining
(to enable inlining)
post_inlining_mode
(default: BLOCK)
BLOCK
FLAT
See also:
post_inlining_renaming
(default: true)
The possible values of post_inlining_renaming are:
true
false
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:
post_porky
(default: false)
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.
porky
porky post-processing phase
post_porky_flags
(to parameterize additional post-processing)
post_porky_flags
(default: "-ucf-opt -unused-syms")
post_s2c_flags
(default: "-omit-header")
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
-Dblocks
-ucf-opt
-unused-syms
See also:
porky
porky
post-processing phase
post_start_inlining_func
(default: [])
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_inlining
(to enable inlining)
post_do_inline
(to force inlining)
post_do_not_inline
(to prevent inlining)
post_inlining_max_nb_calls
(threshold for the number of calls)
post_inlining_max_nb_stmts
(threshold for the body size)
post_transform
(default: true)
pre_common_subexpression
(default: true)
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: [])
post_'' prefix
rather than `` pre_'').
See also:
pre_inlining_time
pre_inlining_time
(default: NEVER)
pre_inlining_time. Possible values are:
NEVER
EARLY
LATE
AUTO
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)
true
/home/jake/spec/power.eta2.html is included.
false
power.eta2.html is included.
rebuild_compound_data
(default: false)
reentrant_rts
(default: true)
Possible values for this variable are:
true
false
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: "")
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)
true
false
See also:
external_functions
(binding time of external functions)
rsd
(default: "$TEMPOHOME/rtcg")
rts_buffer_size
(default: 20000)
rts_compiler_options
(default: "-O0")
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: "")
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:
s2c
s2st
scc_flags
(default: "")
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
-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:
scc
porky_flags
sh_command
(default: "")
sh_command := "
SPE_FLAGS=\"-DSPECIALISATION\";
CHORUS=/udd/pe/chorus/ClassiX1.1/sr;
CHORUSFLAGS=\"-DCOMPAQ386 -DKERNEL -DMULTI_IOM
-I$CHORUS/chorus_3.5\" ";
cpp variable
definitions for parsing.
specialized_entry_point_name
(default: "")
static_locations
(default: [])
entry_point). All other
locations are assumed dynamic.
The variable is a list of strings (location names). A location may be:
"foo".
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.
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:
actx.c
(more precise binding times)
struct_polyvariance
(default: false)
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")
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")
_Gfoo_1_2_3(). When set to foo_3().
verbose_aliases
(default: true)
true
c
and colored files (either color or html).
false
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)
true
false
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)
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
false
See also:
verbose_headers
(default: true)
true
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
Example:
int get_addr(int *x)
/*
binding times of read non_locals: a
residual non-locals in: a
*/
{
return *x/* a[] */;
}
See also:
verbose_rts
(default: false)
true, prints all the commands that build a
run-time specializer.
viewer
(default: emacs)
emacs
.color)
html
.html)
wd
(default: ".")
See also:
cd
(to change the working directory of the SML top-level as well)
arch_dep_dir
(sub-directory for architecture-dependent RT files)
tempo-talk@irisa.fr
tempo@irisa.fr
http://compose.labri.fr
tempo