VSSAD Compilers Pre-Release 0.1 - @(#)README 1.3 9/17/92 13:37:30 The /proj/vssad area contains a set of compilers and simulators developed by the VSS AD group that target superscalar Alpha and VLIW architectures. Much of this software is based on software licensed by Digital from Multiflow Computer, Inc., a now-defunct minisupercomputer company that pioneered the concepts of VLIW architecture and Trace Scheduling compilation. ========================================================================== Machine configuration: This release is built for MIPS-based DECstations. All in all, plan on this area using up 1Gb of disk space and a lot of swap space. - /proj/vssad takes ~500Mb of disk space. A slimmed-down Alpha-only version takes up ~225Mb of disk space. - A coming release of the SPECmarks will add ~150Mb more to this total. - You will need at least 200-300 Mb to do any experimental work. - You will need 150Mb or more of swap space to run the compiler on large, complicated files (like fpppp.f). Ownership and protection: It is important to maintain the source ownership and protection to keep future incremental distributions running smoothly. In general, files are owned by the user "vssadsrc" and are in the group "scsecure". The user "vssadsrc" has the distinguished uid 8799, and is in group 8996, and has a login directory of /usr/vssad (which is a link, described below). The group "scsecure" has the distinguished gid 8996. The "sc" program, which is used for source management, must be set-group-id and in the group scsecure. Pathnames: To use the compiler, your path should include the directory /usr/vssad/bin. The /usr/vssad/bin directory contains special versions of programs like "make", so its important that it come early in the path variable. ============================================================================ /usr/vssad A link to the host binary area under /proj/vssad. In this case, it points to /proj/vssad/vssad.mips. If the host system were of a different architecture, e.g. an alpha, the link /usr/vssad would point to /proj/vssad/vssad.alpha. /proj/vssad All files associated with the VSSAD groups compilers and simulators reside under the the directory /proj/vssad. ./README This file. ./dist A directory containing distribution scripts used by rdist to distribute the /proj/vssad tree from its host machine. ./src The source tree. For source files only. No builds occur here. ./vssad.mips The binary environment for a MIPS-based host, described below. ./vssad.alpha The binary environment for an Alpha-based host, currently empty. =========================================================================== /proj/vssad/src: The src directory contains all of the source and documentation for the compiler, simulator, runtime environment, and build tools. The source tree should contain ONLY sources, no machine generated files or links should ever appear in this area. The machine generated files are created in the /proj/vsssad/vssad.*/build.*/ trees described below. The top-level files and directories are: /proj/vssad/src/bench The SPECmarks along with the usual set of industry standard benchmarks. [This area is not yet being distributed; it should be sent out by the 12/91]. /proj/vssad/src/doc Old Multiflow documentation, technical notes, talks, release notes, and papers written on the compiler. Old Multiflow mail archives containing technical compiler discussions [mail archives not distributed to save space]. /proj/vssad/src/man Source for old Multiflow man pages for the compiler and other compiler-related programs. /proj/vssad/src/release Source for the things that go into /usr/vssad/release. This includes source for the compilers, zippy assmebler/simulator, and the C, Fortran, and Math runtime libraries. Described in more detail below. /proj/vssad/src/tape Very old Multiflow source for some compiler tools. Among other things, contains the source for the Bulldog compiler. [This area not distributed to save space]. /proj/vssad/src/test The source for the compiler test suite. Hints on how to use the test suite are given below. /proj/vssad/src/tools Source for tools used to build and maintain the compiler. In particular, the sc and make tools are described below. =========================================================================== /proj/vssad/src/release Source for the compiler, compiler related utilities, zippy and the cross libraries. =========================================================================== /proj/vssad/vssad.mips Tree of all compiler-related binaries built to run on the Decstation. /proj/vssad/vssad.mips/.cshrc /proj/vssad/vssad.mips/.login /proj/vssad/vssad.mips/.rhosts /proj/vssad/vssad.mips/PATH The vssadsrc users .cshrc and .login files. The .rhosts file is set up to allow the vssadsrc user to do rdists from vliw.bxb.dec.com and vssad.bxb.dec.com. PATH is used to put /usr/vssad/bin on the PATH variable. /proj/vssad/vssad.mips/build.* Clones of /proj/vssad/src containing executables and .o's built to run on a MIPS that generate code for other machines, and/or runs (or gets simulated) on other machines. In particular... /proj/vssad/vssad.mips/build.alpha A clone of /proj/vssad/src containing executables and .o's built to run on a MIPS and generate Alpha code that gets simulated by running on a MIPS. /proj/vssad/vssad.mips/bin A set of MIPS executables used to build and run the compiler. Most are built in /proj/vssad/vssad.mips/build.alpha/tools. If the link "/usr/vssad" points to "/proj/vssad/vssad.mips" then "/usr/vssad/bin" will be this directory. Remember that "/usr/vssad/bin" should be on your PATH. /proj/vssad/vssad.mips/release A set of compilation system release areas used through the compilers "-v" switch. In this distribution, the release area contains an "alpha" and an "alpha.dev" area. The "alpha" area is a set of frozen executables targeting Alpha. The "alpha.dev" area is a set of links into the "build.alpha" subtree. The "release" area points to the default release. /proj/vssad/vssad.mips/src A link to /proj/vssad/src. ============================================================================ Building the compiler, simulator and runtime environement: Known list of prerequisites for building the compiler: /usr/vssad/bin/make - Multiflow make m4 - m4 macro preprocessor yacc - yacc parser generator liby.a - yacc library lex - lex lexer generator libl.a - lex library libm.a - math library Go to the directory /usr/vssad/build.alpha and type: make >& Make.{hostname}.log.# For more selective builds you can specify the following make variables: These three variables determine the compilers used when cross compiling for the target machine: TARGET: the target architecture (null means build for the default, which is currently 'alpha'). TARGET_CC: the C compiler used in building code to run on the target. Default is determined by makefiles below this one, and is currently 'scc -v alpha.dev -Dalpha'. To build libraries for OSF, set this to 'scc -v osf -Dalpha -DOSF' on the command line. TARGET_FC: the Fortran compiler used in building code to run on the target (currently used only to build some stubs in the Fortran library). Default is determined by makefiles below this one, and is currently 'sfc -v alpha.dev -Dalpha'. TARGET_AR: If target has a different archive format, we need a target ar to archive the libraries. These two variables govern which compilers are used for building host-resident programs. HOST_CC: the C compiler used to build code to run on the host (currently cc). HOST_FC: the Fortran compiler used to build code to run on the host (currently f77, and not currently used by anyone in the build). This variable specifies the root of the installed tree. DESTDIR: The root of the installed tree. Currently defaults to "/proj/vssad/vssad.mips/release/alpha". To selectively build part of the tree the following targets may be specified: fc_cc_shell - really scc and sfc, which are the base program that invokes the real cc (rcc) or fc (rfc). It is the program that parses the -v switch to allow support for various versions of the compiler. aux - the real cc (rcc) and fc (rfc) which is used to invoke the various phases of the compilation. cpp - a c preprocessor, not currently used. compiler - the c and fortran compilers themselves. zippy - the zippy assember and simulation environment. utils - some utilities for ifprobbing a program. mfl - a performance estimator. or the libraries... libc - the cross compiled c library libm - the cross compiled math library flib - the cross compiled fortran libraries ============================================================================ Running the compiler: scc - the C compiler. sfc - the Fortran compiler. Basic usage is exactly like standard Unix "cc" or "fc" (or "f77") commands, e.g.: hello.c: main () {printf("Hello world\n");} Compile: scc -c hello.c Link: scc -o hello hello.o Run: hello hello.f: print *,'Hello world' end Compile: sfc -c hello.f Link: sfc -o hello hello.o Run: hello These compilers produce MIPS .o's using a Zippy compiled simulator (below). These .o's can be linked with other Zippy libraries to produce MIPS executables that correctly model the performance and semantics of the machines being simulated. Don't use "as" and "ld" directly, rather use them through scc or sfc. Use the "-d" switch to get an idea of the programs being run in each of the phases of the compiler, To see the simulated .s files, use the either the -S switch (produces foo.s) or the -ms switch (produces both foo.s and foo.o). E.g, scc -c -ms foo.c If you're curious about Zippy's machinations, see below. =============================================================================== Zippy Simulator Zippy is a code translation-based simulator. In conjuction with compiling alpha code using the vssad Alpha compiler, zippy allows you to run the code on a mips machine, as well as generate a performance characterization. Zippy consists an assembler that takes in Alpha assembly language and generates mips assembler that emulates the Alpha architecture as well acting as a performance model for a particular implemention of the archictecture. The current version models ev4. Using zippy is very much like a normal compile/build/run sequence. Using the vssad compiler, the sequence for compiling hello.c would be: scc -o hello hello.c hello The following compiler switches are useful for debugging under zippy. -ms generates .s files -mag retains debugging info in mips output -maS generates .z file with mips assembler output If you use -ms and -mag then the resulting program can be debugged at the Alpha assembly language level using the standard mips debuggers, e.g. dbx. Zippy also allows some addition switches on the run. These are started with a special switch, -ZZ. They are terminated with -- to separate the zippy switches from the programs own switches. The current zippy usage is: [Program_Options] -ZZ [Zippy_Options] -- [Program_Options] Zippy_Options: -c enable cache model -h usecs set hardware clock interval -n name set the name of the program -o [file] send statistics to file (default is .stat) -P [file] send PC histogram to file (default is .pch) -p enable profiling (output to mon.out) -r size set size of return address stack -S size set size of stack -s stat enable stripchart for stats: c cache o operations per cycle t ticks per instruction -x [rep x]int,[[rep x]int] set stripchart interval: rep optional repeat count int interval in cycles /proj/vssad/src/release/zippy/dev The source for the zippy simulator. /proj/vssad/src/release/zippy/dev/include/ Include files used by various pieces of zippy. /proj/vssad/src/release/zippy/dev/as/ The source code for the zippy alpha to mips code-translator. Automatically invokes mips /bin/as on resulting file. /proj/vssad/src/release/zippy/dev/ld/ A linker for objects generated by the zippy assembler. Does address fixup for the emulated code, and automatically invokes mips /bin/ld with proper support libraries. /proj/vssad/src/release/zippy/dev/libc/ A minimal version of libc for use in debugging zippy. /proj/vssad/src/release/zippy/dev/libzippy/ The zippy runtime support library. Includes emulation routines for the cache hierarcy, statistics gathering and low-level support for the zippy simulations. /proj/vssad/src/release/zippy/dev/pch/ A tool for analyzing the PC histograms that zippy can generate. /proj/vssad/src/release/zippy/dev/time/ A version of /bin/time that reports simulated execution time rather than real execution time. =============================================================================== sc - a source management tool. The 'sc' command is the interface to the files stored under /proj/vssad/src. There are eight subcommands: checkout, update, install, create, uncheckout, retrieve, link, unlink. - sc link [ module { file } ] This commands creates a symbolic link to the named file in the named module. If no file name is given, it creates a link to all the files in the named module. If no module name or file name is given, you must be connected to '/x/LUSER/src', and all the files in all the modules are linked. In all cases, a link is NOT created if a file (or link) of the same name currently exists. Use unlink to remove unwanted symbolic links. - sc checkout module { file } This command checkouts the named files from the sc archive for the named module, and places them in the connected directory. These files are 'editable', i.e., the sccs-id is not expanded. No one else can checkout a file while you have it checked out. If no file name is given, all the source files for a module are checked out. - sc update module { file } This command updates the sc archive for the module with the named files. These files must have been previously checked out, and must be 'editable'. Releasable copies of the same files are written into the RELEASE directory as determined by the .sc_path. If no file name is given, all files in the current directory which have been checked out and which are not symbolic links are updated. (Note change: In previous version of the sc command, files where deposited in the connected directory.) - sc create module file { file } This command is like update. It is used if the file does not currently exist in the sc archive for the module. The file must be 'editable'. - sc uncheckout module file { file } [THIS WILL DELETE AND RELINK THE FILE, BE SURE YOU WANT TO DO THAT!] This command unchecks out a file, if you checked it out by mistake. - sc retrieve module { file } This command retrieves a 'releasable' copy of the file from the sccs archive. This should only be needed if the released copy of the file in the module directory is not up-to-date. If no file name is given, all the source files for a module are checked out. - sc unlink [ module { file } ] Like link, but the symbolic links are removed. =============================================================================== Extensions to make Multiflow added ttwo features to make for use by the compiler group to build the compiler and the assembler. The new make is compatible with the old make, so existing makefiles will work unchanged. Include Files ------------- From make's point of view include files present different semantics than the ':' construction provides for. A new construction, the arrow, has been added to reflect include file semantics. This is illustrated in the following makefile. prog: test.o test.o: test.c test.c <- test.h "test.o: test.c" can be read "test.o is built from test.c". "test.c <- test.h" can be read "test.c includes test.h". Now notice the difference in semantics. For the colon operator if test.c is newer than test.o, test.o will be rebuilt as expected. For the arrow operator if test.h is newer than test.c, it is not test.c that is built, it is test.o. There are many advantages to the arrow syntax. First, makefiles can now directly reflect the actual include file dependencies. Without the arrow, the include file dependancies have to be flattened as shown below: # With the arrow syntax a.o: a.c a.c <- a.h a.h <- b.h b.h <- c.h # Without the arrow syntax a.o: a.c a.h b.h c.h This flattenning prevents dependancies from being expressed in a modular fashion. The author of module a is aware that a.h includes b.h, which is fine. With the arrow syntax the author of module a writes "a.h <- b.h" and is done. It is up to the author of module b to define what b.h includes. Without the arrow syntax, the author of module a must be aware of the entire include file dependancy tree. Thus a change in include file dependancies in module b or c will require changing the makefile dependancies in module a. Clearly a management problem. There is a workaround to this problem. The construct "a.h <- b.h" can be expressed without the arrow syntax as: a.h: b.h touch a.h This is essentially the solution used by the compiler group. This solves the modularity problem. But it does not allow circular include dependancies. Which, by the way, are being introduced into the compiler by inlines. This solution also has the problem of artificially changing the dates of include files. That is, a change in dates does not necessarily reflect a change to the sources. A final advantage to the arrow syntax is that it will work with symbolic links. The touch workaround can be fixed to work with symbolic links, but it has to convert the link to a plain file. Rules which build multiple files -------------------------------- There are cases where one set of rules builds more than one file. A new addition to make allows this to be expressed directly. A list of files to the left of the colon may be enclosed in parens. These files are then treated as a unit. (a b): l m n build a build b When make must build a, it will also at the same time make sure b is up to date. Note the similarity in syntax to the following: a b: l m n build a build b This is simply a shorthand for: a: l m n build a build b b: l m n build a build b The importance in the difference of the semantics for the paren and non-paren cases can be seen from the following makefile. all: a e a: b touch a b: c touch b c: d touch c e d: l m touch e touch d At the start assume everything is up-to-date except e. Make will first try to build a, b, c, and d. These will all be up to date. Then make will try to build e. E is out of date so it will run the rules which build e AND d. Now e is up to date and you are done. Unfortunatly if the make is run a second time a, b, and c will be built. Clearly having to run make twice to bring everything up to date is a problem. If the last rule is changed to use the paren syntax. (e d): l m touch e touch d Then when it comes time to build d, make will check that e and d are both up to date. Since e is out of date, e and d will be built, followed by a, b, and c. Just what you want. Also, in the non-paren case, make -n will run the rules to build e and d twice. Make -n using parens will build e and d only once. There is a non-paren workaround to describe dependancies which build more than one file. Examine the case where a source code generator is used to simultaneously build tu.H and tu.C. tu.H: flag touch tu.H tu.o: flag flag: C_source_file_generator tu.H tu.C # Build tu.H and tu.C touch flag The flag is used to tie tu.H and tu.C together. If the generator is executed, flag will be touched which will cause anything using tu.H or tu.C to be rebuilt. This workaround can be "fooled". Say everything is up-to-date and then tu.H is deleted. The makefile will touch tu.H, creating an empty file, and never run the source file generator. Summary ------- The arrow syntax promotes modularity and directness. It is essential for the compiler group. However, its usefullness is not limited to the compiler group. Customers will find it a useful addition. The paren syntax promotes directness and simplicity. Again, customers will find it a useful addition. ========================================================================== Compiler switches Below is the C compiler man page; the Fortran compiler man page is very similar. Both may be found in /proj/vssad/src/man/compiler/rel.2.2. NAME cc - C compiler SYNOPSIS cc [ option ] ... file ... DESCRIPTION Cc is the Multiflow TRACE/UNIX C compiler. It supports the C language, as defined by Kernighan and Ritchie in The C Program- ming Language and Multiflow-specific extensions to the language. Multiflow extensions are defined in the C Language Notes. A standard C compilation command looks like this: cc -o outputfile source1 source2 . . . sourceN where outputfile is the name of the object file (or executable file) that you wish to create, and source1 through sourceN are C source files and compiled object modules. The C compiler deter- mines how to process these files on the basis of their filename, as follows: Files whose names end with `.c' are taken to be C source pro- grams; they are compiled, and each object program is left on the file whose name is that of the source with `.o' substituted for `.c'. The `.o' file is normally deleted, however, if a single C program is compiled and loaded all at once. By default, `.c' files are compiled with all Multiflow extensions disabled (i.e. strictly in conformity with Kernighan and Ritchie). In the same way, files whose names end with `.s' are taken to be assembly source programs and are assembled, producing a `.o' file. Optimization is in effect by default. This default optimization yields ideal performance for most C programs. For more informa- tion about optimization, see the -O options (below). The following options are interpreted by cc. They are grouped according to category. Output Files This set of options determines which stages the compiler will execute, and which files it will leave after finishing. -o output Give the name output to the executable file produced by the loader, rather than the default name a.out. If this option is used, and the file `a.out' already exists, it will be left undisturbed. -c Suppress the loading phase of the compilation; do not delete the '.o' files produced by the assembler. These files may be loaded by cc or ld at a later time. -- -- Multiflow TRACE/UNIX 1 CC(1) March 18, 1988 -S Compile the named C programs, and leave the assembler- language output on corresponding files suffixed `.s'. No `.o' file is produced. -E Run only the standard preprocessor on the named C programs, and send the result to the standard output. (See ``Prepro- cessing.'') -M Run only the standard preprocessor on the named C programs, requesting it to generate Makefile dependencies and send the result to the standard output. (See ``Preprocessing.'') Preprocessing Before compiling the program, the compiler invokes the standard preprocessor (cpp), which provides features like macro expansion --- and conditional compilation. Any standard C reference book describes cpp's features. The options in this set control cpp. --- --- -Dname=def ---- --- -Dname ---- Define the name to the preprocessor, as if by `#define'. If ---- no definition is given, the name is defined as "1". -Uname ---- Remove any initial definition of name. ---- -Idir --- `#include' files whose names do not begin with `/' are always sought first in the directory of the file argument, ---- then in directories named in -I options, then in directories on a standard list. -C Prevent the preprocessor from eliding comments. Normally, the preprocessor replaces all commands (i.e. all characters falling between /* and the next */) with a single space. -E Run only the standard preprocessor on the named C programs, and send the result to the standard output. -M Run only the standard preprocessor on the named C programs, requesting it to generate Makefile dependencies and send the result to the standard output. Dependencies are generated by analyzing the program's #include statements. Debugging and Profiling The options in this group enable debugging and profiling. Note that most profiling features can also be enabled through pf. -- -g Have the compiler produce additional symbol table informa- tion for dbx (1). Also pass the -lg flag to ld (1). --- -- -p Arrange for the compiler to produce code which counts the number of times each routine is called. If loading takes place, replace the standard startup routine by one which 2 Multiflow TRACE/UNIX March 18, 1988 CC(1) automatically calls monitor (3) at the start and arranges to ------- write out a mon.out file at normal termination of execution of the object program. An execution profile can then be generated by use of prof (1). To create a ``profiling'' ---- version of a program, it is only necessary to relink the program with the -p option. Recompilation is not necessary. -pg Causes the compiler to produce counting code in the manner of -p, but invokes a run-time recording mechanism that keeps more extensive statistics and produces a gmon.out file at normal termination. Also, a profiling library is searched, in lieu of the standard C library. An execution profile can then be generated by use of gprof (1). To create a ``pro- ----- filing'' version of a program, it is only necessary to relink the program with the -pg option. Recompilation is not necessary. -prob generate - Create a probability database directory, if it doesn't exist; generate object files that will create a branch count statistics file upon execution. The default name of the database directory is database.ifprob; it is created in the current working directory (i.e., the compilation directory). The default name of the statistics file is ifprob.out; it is created in the execution directory. -prob use - Use the data in the probability database directory to guide trace selection during compilation. By default, the com- piler assumes that the branch probability database file is named database.ifprob, and that the probability statistics file is named ifprob.out, and is located within the database directory. The source code may not be changed between com- pilation with -prob generate and compilation with -prob use. - - -prob dir dir - --- Use the name dir for the probability database directory, --- rather than the default name. This option must combined with either -prob generate or -prob use. - - -prob file file - ---- Use the filename file for the probability statistics file, ---- rather than the default name. This option must be combined with -prob use. - -tb Pass arguments in a way that allows dbx and program trace- --- backs to access function arguments. This option is requested implicitly by -g. -F0 If compiled with this option, when the executable file (a.out file) produced by this compilation receives a signal, it will not generate a stack trace or invoke dbx. This --- option is in effect by default for C programs. Multiflow TRACE/UNIX 3 CC(1) March 18, 1988 -F1 Upon receiving any of the following signals, the executable program will terminate and generate a stack traceback: SIGQUIT, SIGIL, SIGTRAP, SIGIOT, SIGEMT, SIGFPE, SIGBUS, SIGSEGV, and SIGSYS. -F2 The executable program will terminate and generate a stack traceback upon receiving any of the signals for -F1, plus any of the following: SIGHUP, SIGALRM, SIGTERM, SIGXCPU, SIGXFSZ, SIGVTALRM, SIGPROF, SIGUSR1, and SIGUSR2. -F3 The executable program will terminate and invoke the dbx --- debugger upon receiving any of the signals for -F1 and -F2, plus either of the following: SIGINT and SIGPIPE. Optimization This set of options determines how the compiler will optimize your program. Optimization is in effect by default (i.e. -O2 compilation). We only give rough definitions of the different optimization types. The defaults are subject to change, and differ between different TRACE models. -O Equivalent to -O2. This option is in effect by default. -On This series of options controls which optimizations the com- - piler performs, as follows: -O0 No optimization -O1 All scalar optimizations -O2 Minimal loop unrolling and trace scheduling compilation -O3 Loop unrolling (-H1), trace scheduling compilation -O4 Algebraic identities for intrinsic functions -O5 Heavy loop unrolling (see -H4) Each successive option provides additional optimizations in addition to those performed at the previous levels. By default, the option -O2 is in effect: this will provide ideal performance for most C programs. -O0 should only be used for debugging with dbx. -O4 and -O5 should be used --- with care and on the basis of experimentation. In any large program, a few routines may benefit from these optimization levels. They should not be used for programs as a whole. -Hn This series of options controls loop unrolling. They over- - ride the loop unrolling that is implicitly requested by the -On optimization options (above). The -H options are: - -H0 No unrolling (default for -O0 and -O1 -H1 Basic unrolling (default for -O3 and -O4) -H2 Aggressive loop unrolling -H3 Heavy loop unrolling -H4 Very heavy unrolling (default for -O5) For most compilations, you will not need to specify this option. The more aggressive loop unrolling options (-H2 4 Multiflow TRACE/UNIX March 18, 1988 CC(1) through -H4) should be only be used for routines where experimentation has shown that they are effective. These will typically be routines whose execution time is dominated by a relatively simple loops. -checkout Minimize compilation time. The -checkout option must not be used for production code; programs compiled with the this option will run slowly. -sb trace n - - Allow the compiler to use short branches for the first n - traces of a function, provided these traces are inner loops. If n is negative, short branches will be used for all inner - loop traces. If n is zero, short branches will not be used. - -bc trace n - - On a TRACE 14 or TRACE 28, allows the compiler to perform additional memory reference optimizations across branches. These optimizations are performed on the first n traces of - each function, provided that trace belongs to an inner loop. If n is negative, these optimizations will be performed on - all inner loop traces. If n is zero, these optimizations - will not be performed. This option has no effect for the TRACE 7. -safe Do not allow either short branches or further memory refer- ence optimization. It overrides the -sb trace and -bc trace - - options, which are implicitly in effect with -O3 compilation (the default). -lb limit n - - Set the ``loop branch limit'' to n. The compiler ceases to - unroll any loop when the unrolled loops body has n internal - branches. Branches to code outside of the loop body are not counted, and therefore do not inhibit unrolling. That is, -lb limit puts an implicit limit on loop unrolling, supple- - menting the explicit limit provided by any source code directives or command line options. By default, the loop branch limit is 0; branches internal to a loop inhibits loop unrolling. Language Definition These options control enable and disable certain extensions to the language. By default, the C compiler obeys the language definition given by Kernighan and Ritchie, with no extensions. -K+R Use the language definition given by Kernighan and Ritchie, with no extensions. This is the default. -mfinline Allow inline expansion, as described in the C Language - -------- Notes. ----- Multiflow TRACE/UNIX 5 CC(1) March 18, 1988 -align n - This option indicates that all data items larger than n - bytes obey their optimal alignment, where n is 1, 4, or 8. - For example, the option -align 1 means that any data object may start at any address (i.e. the program does not obey any alignment restrictions). -align 4 means that all data items are aligned correctly, with the possible exception of double precision (64-bit) references (which may occur on word, rather than double-word, boundaries). By default, alignment is eight, stating that the program always observes optimal alignment. Setting the alignment option to a lower value does not in itself reduce perfor- mance; however, programs that do not obey all alignment rules will suffer from reduced performance. Argument Passing This group of options lets you determine how arguments are passed between a function and the routines it calls. Arguments may be passed in registers or in memory. By default, the C compiler uses a very conservative strategy; at a call, functions place their arguments both in registers and memory, so that any func- tion will be able to read it arguments, regardless of where it expects to find them. This strategy is not optimal but always works. These options let you select optimal argument passing strategies. How the called function uses pointers determines whether or not any argument passing strategy is valid. Three cases are of interest. First, if a function never refers to an argument via a pointer (i.e. the function never takes the address of an argu- ment), there are no restrictions on the argument passing stra- tegy. Second, if a function refers to an argument via pointer plus an offset, the arguments must be passed through memory. All functions that use the ``varargs'' macro set fall into this category. Third, if a function refers to an argument via a pointer, but never uses an offset, either argument passing stra- tegy is valid. The compiler cannot distinguish between cases 2 and 3, and therefore treats such functions with caution (unless advised otherwise). For a complete discussion of these strategies, refer to the C - Language Notes. -------- ----- -ab The calling function generates an argument block in memory and loads the arguments into registers. The called function may read arguments either from memory or registers. When compiled with this option, a function reads its arguments from registers unless it takes the address of an argument (i.e. generates a pointer to an argument); in this case, it reads its arguments from memory. This option is in effect by default. -ar Functions read their arguments from registers, unless the function is listed with the -uv option (below). The calling function loads arguments into registers and does not create 6 Multiflow TRACE/UNIX March 18, 1988 CC(1) an argument block in memory, unless the function it is cal- ling is on a list of library functions known to take the address of an argument, or is listed with the -uv option. The compiler prints a warning when it compiles a function that takes the address of an argument, and is not listed with -uv. The group of standard library routines which cannot read their arguments from registers is printf, fprintf, sprintf, scanf, fscanf, sscanf, execl, execle, and syslog. This is the optimal calling strategy. It will work for vir- tually all programs. -arw Identical to -ar, except that no warnings are given. -uv name ---- This option identifies name as a function for which argu- ---- ments must be passed in memory (i.e. argument passing in registers is invalid). Functions falling into this category either use the ``varargs'' macro set, or refer to an argu- ment via a pointer and an offset. -nsv Normally, the compiler assumes that functions with the names listed above (i.e. printf et. al.) cannot read their argu- -- -- ments from registers. This option tells cc to discard that -- list, and to assume that functions with these names can read arguments from registers. -tb The calling function always generates an argument block in memory, for use by dbx and tracebacks. This option does not --- otherwise modify the argument passing strategy. Libraries These options let you link C programs with different subprogram libraries, in addition to the standard libraries. They also con- trol whether the program will use the standard shared libraries. Libraries that are distributed as a part of TRACE/UNIX are located in the directory /usr/lib or /libsh. -lx Link with the library file named `libx.a'. The loader will - - search for this file in any directories specified with the -L option, in the directory `/lib', and in the directory `/usr/lib'. Libraries are searched in the order in which they appear on the command line; therefore, they should nor- mally appear at the end of any cc command. This flag is -- passed directly to the loader. -Ldir --- Library archives are sought first in directories named in -L options, then in directories on a standard list. This flag is passed directly to the loader. -slib Link with the ``shared libraries'' located in `/libsh', Multiflow TRACE/UNIX 7 CC(1) March 18, 1988 rather than the ``standard'' libraries. -noslib Link with the ``standard libraries,'' rather than the ``shared'' libraries. This is the default for C. Cross Compilation and Version These options select different versions of the Multiflow C com- piler, if they are available on your system. They also let you compile code for other TRACE models, and for different memory configurations. By default, the compiler generates code for the TRACE model and memory system on which it is running. TRACE executable modules are upward-compatible, and all memory configurations are mutually compatible. For optimal performance, compile for the TRACE model and memory configuration on which you will run the program. -width n - Compile for a TRACE model n/200 computer. N must be 7, 14, - - or 28. By default, the compiler will generate code for the model on which it is running. -cards n - Compile for a TRACE computer with n memory controllers. N - - must be either 2, 4, or 8. By default, the compiler will generate code for the memory configuration of the system on which it is running, unless you have specified the -width option; in this case, the compile will, by default, generate code for the minimum legal memory configuration for this width. -banks n - Compile for a TRACE computer with n (total) memory banks. N - - must be 8, 16, 32, or 64. In general, the total number of memory banks is 2 times the number of memory controllers times the number of daughter cards per controller. By default, the compiler will generate code for the memory con- figuration of the system on which it is running, unless you have specified the -width option; in this case, the compile will, by default, generate code for the minimum legal memory configuration for this width. -v version ------- Use the compiler identified by version, rather than the ------- default compiler. For example, fc -v 1.4.2 requests the compiler of release 1.4.2, if this compiler is available. Options for Assembling and Loading This group of options lets you pass options from the cc command -- to the loader (ld) or the assembler (as). Note that any filename -- -- or option that fc does not recognize is automatically passed to -- the loader. The manual entry for ld (1) describes loader -- options; the entry for as (1) describes assembler options. -- 8 Multiflow TRACE/UNIX March 18, 1988 CC(1) -mac Pass the the option -c to the assembler as. - - -- -mlc Pass the the option -c to the loader ld. For example, the - - -- options -mlJ ffff0000 are passed to the loader as -J ffff0000. -J is passed via -ml: its argument, ffff0000, is passed because it isn't otherwise recognized by the com- piler. Terminal Output This group of options limits the output that the compiler will send to your terminal. -w Suppress warning diagnostics. -mv Display a banner line, including the version number of the compiler. -mve Display a banner line, including the version number of the compiler, and terminate; do not proceed with compilation. Other Options -temp=directory --------- Create temporary files used during compilation in directory, --------- rather than in /tmp (the default). An error occurs if directory is missing; if the given path is not the name of --------- the directory; or if the given path is not writable. Other arguments are taken to be either loader options or C- compatible object programs, typically produced by an earlier cc -- run, or perhaps libraries of C-compatible routines. These pro- grams, together with the results of any compilations specified, are loaded (in the order given) to produce an executable program with name a.out. FILES file.c input file file.o object file a.out loaded output /tmp/{m4,cpp,com}* temporary /usr/compiler/release/lib/cpp preprocessor /usr/compiler/release/lib/ccom7 compiler, TRACE 7 /usr/compiler/release/lib/ccom14 compiler, TRACE 14 /usr/compiler/release/lib/ccom28 compiler, TRACE 28 /usr/compiler/release/lib/crt0.o runtime initialization /usr/compiler/release/lib/libc.a standard library, see intro(3) ----- /usr/compiler/release/usr/lib/libc p.a profiling library, see - intro(3) ----- /usr/include standard directory for `#include' files mon.out file produced for analysis by prof(1) ---- gmon.out file produced for Multiflow TRACE/UNIX 9 CC(1) March 18, 1988 analysis by gprof(1) ----- SEE ALSO C Language Notes - -------- ----- B. W. Kernighan and D. M. Ritchie, The C Programming Language, --- - ----------- -------- Prentice-Hall, 1978 B. W. Kernighan, Programming in C-a tutorial ----------- -- - - -------- D. M. Ritchie, C Reference Manual - --------- ------ monitor(3), prof(1), gprof(1), adb(1), ld(1), dbx(1), as(1) DIAGNOSTICS The diagnostics produced by C itself are intended to be self- explanatory. Occasional messages may be produced by the assem- bler or loader. BUGS Option names may change with future releases of the compiler. ========================================================================== Internal compiler switches There are a large number of internal compiler switches, described below. To set one, use the "-mXXXX" switch when compiling, e.g.: -mP1OPT_print_version=TRUE -mP1OPT_max_rec_size_in_regs=16 Try "scc -d" or "sfc -d" to get a taste for the range of switch settings. *********************************************************************** PHASE 1 OPTIONS *********************************************************************** VARIABLE BOOL P1OPT_print_version A banner and version ID are printed to standard error when the compiler is started if and only if this is TRUE. VARIABLE BOOL P1OPT_print_phase2_compilation_script The Phase 2 compilation script is printed to standard output when the compiler is started if and only if this is TRUE. VARIABLE BOOL P1OPT_exit_without_compiling If this is TRUE, main will just parse the command line and optionally print some of its initial informative messages, but will exit before actually compiling anything. VARIABLE BOOL P1OPT_emit_dbx_info If this is TRUE, dbx symbol table information will be emitted by the front ends to GLOB_as_ouput_file. VARIABLE INT P1OPT_max_rec_size_in_regs This variable gives the maximum size, in bytes, of records that may be passed or returned in registers. When a record's size is less than or equal to this value, the front ends create alias variables within the Phase 2 record declaration which correspond to the registers in which the record may be passed or returned. When a record's size is greater than this value, the record will not be passed or returned in registers. This value must be greater than or equal to the maximum of the sizes of the primitive data types, which is currently 8. VARIABLE P1OPT_CALL_DEFAULT P1OPT_call_default This variable gives the default argument location operator part for CALL operators. It must be one of P1OPT_CALL_DEFAULT_REGS, P1OPT_CALL_DEFAULT_MEM, or P1OPT_CALL_DEFAULT_BOTH. VARIABLE P1OPT_ENTRY_DEFAULT P1OPT_entry_default This variable gives the default argument location operator part for ENTRY operators. It must be one of P1OPT_ENTRY_DEFAULT_REGS, P1OPT_ENTRY_DEFAULT_MEM, or P1OPT_ENTRY_DEFAULT_MEM_IF_ADDR_TAKEN. VARIABLE BOOL P1OPT_force_call_args_in_mem This variable indicates if function arguments must be passed in memory. When its value is TRUE, the argument location operator part for CALL operators must be ARGS_MEM or ARGS_BOTH. If it otherwise would have been ARGS_REG, it becomes ARGS_BOTH. VARIABLE REG_SAVER P1OPT_reg_saver_default This variable gives the default register saver operator part for CALL operators. It must be one of CALLER_SAVES or CALLEE_SAVES. VARIABLE BOOL P1OPT_force_uninitialized_to_data This variable indicates if packets containing only uninitialized variables (i.e., not explicitly initialized by the user) should be allocated in the data section rather than the bss section. When its value is FALSE, such packets are allocated in the bss section. When its value is TRUE, such packets are allocated in the data section if their size is less than or equal to the value of P1OPT_max_size_forced_to_data. VARIABLE INT P1OPT_max_size_forced_to_data This variable gives the maximum size, in bytes, of packets which are allocated in the data section instead of in the bss section. Packets whose initializers all have the value zero are allocated in the data section if their size is less than or equal the value of this variable; otherwise, they are allocated in the bss section. Note that packets that are not initialized are also allocated in this manner when P1OPT_force_uninitialized_to_data is TRUE. By convention, the value -1 indicates infinity. In this case, all eligible packets are allocated in the data section. VARIABLE BOOL P1OPT_generate_ifprob_data This variable is used to turn in the 'ifprobing' facility. If it is turned on then all branch statements will have code added to them to count the number of times they are entered and the number of times that they are true. This information is written to a file specified using the option P1OPT_ifprob_database_file. VARIABLE BOOL P1OPT_use_ifprob_data If this variable is TRUE then the values of the branching probabilities are taken from previously generated runs of the program. The probabilities are read from a file specified with the option P1OPT_ifprob_database_file. If no entry exists for a certain branch, then a default probability of 0.5 is assumed. VARIABLE CHAR *P1OPT_ifprob_database_file This variable is used to specify the name of the file to be used to generate the ifprob database info. VARIABLE CHAR *P1OPT_ifprob_source_file_name This variable is used to store the name of the current file being processed. VARIABLE BOOL P1COPT_ansi Allow ANSI function prototypes and const's. VARIABLE P1COPT_EXTDECL P1COPT_extdecl_style This variable gives the style used to determine allocation and loader information for external data declarations. It must be one of P1COPT_EXTDEF_PDP11, P1COPT_EXTDEF_BSD, or P1COPT_EXTDEF_TRUE_C. It should only be changed outside of the module level. P1COPT_EXTDECL An ENUM indicating which style to use in determining allocation and loader information for external data declarations, one of: P1COPT_EXTDECL_PDP11 P1COPT_EXTDECL_BSD P1COPT_EXTDECL_TRUE_C The mapping from external data declaration to Phase 2 allocation and loader information for each style is: DECLARATION SIZE PDP11 BSD TRUE_C --------------- ----- ------- ------- ------- int a = 1; KNOWN STATIC STATIC STATIC DEFINED DEFINED DEFINED int a; KNOWN STATIC STATIC STATIC COMMON COMMON DEFINED extern int a; KNOWN STATIC STATIC STATIC COMMON EXTERN EXTERN int b[] = {1}; KNOWN STATIC STATIC STATIC DEFINED DEFINED DEFINED int b[]; UNKNOWN STATIC STATIC EXTERN EXTERN extern int b[]; UNKNOWN STATIC STATIC STATIC EXTERN EXTERN EXTERN VARIABLE INT P1COPT_max_rec_size_inline_copy This variable gives the maximum size, in bytes, of structures or unions for which the front end will generate a sequence of loads and stores inline to effect an assignment, rather than calling the bcopy intrinsic. Note that the value of this variable is assumed to be greater than or equal to the value of P1OPT_max_rec_size_in_regs. With this restriction, the front end does not have to materialize a function value before calling bcopy. VARIABLE BOOL P1COPT_generate_selects This variable indicates if IL-1 SLCT_* operations will be generated. VARIABLE BOOL P1COPT_mloops Allow Multiflow Loops. VARIABLE BOOL P1COPT_sqrt_instruction; This variable indicates whether to use the IL-1 FSQRT operation for calls to sqrt. The call to sqrt is only substituted with the FSQRT operation when the type of sqrt() is double, its argument is type double, there is only one argument and this variable is TRUE. VARIABLE BOOL P1COPT_fabs_instruction; This variable indicates whether to use the IL-1 FABS operation for calls to fabs. The call to fabs is only substituted with the FABS operation when the type of fabs() is double, its argument is type double, there is only one argument and this variable is TRUE. VARIABLE BOOL P1COPT_recognize_inline_keywords; If TRUE, the lexer considers the tokens "inline," "inline_mode," "inline_module," "inline_use," and "noinline" as keywords. VARIABLE BOOL P1COPT_recognize_directive_keywords; If TRUE, the lexer considers the tokens "assert_eq", "assert_ge", "assert_gt", "assert_le", "assert_lt", "assert_ne", "if_prob", "interleave_amount", "precondition_amount", "trip_count", and "unroll_amount" as keywords. VARIABLE INT P1COPT_inline_limit When the user does not explicitly specify an inline nesting limit on a call to a function that is to be expanded in line, the value of this option is used for that limit. VARIABLE INT P1COPT_structure_align This variable gives the smallest preferred alignment for a Phase 2 record variable created for a user-specified structure, in bytes (note that it is an INT, not an ALIGN). It must be either 1, 2, 4, or 8. The preferred alignment of a Phase 2 record created for a user-specified structure is the maximum of this variable and the preferred alignments of the top level components of the record. VARIABLE CHAR *P1COPT_varargs_functions This variable points to a character string containing the names of functions which are to be compiled as varargs functions, i.e., functions which take the address of a formal parameter in order to access other formal parameters. The format format of the character string is a sequence of C function name identifiers separated by commas. VARIABLE BOOL P1COPT_warn_if_param_addr_taken This variable controls whether a warning will be issued if a function which is being compiled to take arguments from registers has the address of any of its formal parameters taken. VARIABLE INT P1COPT_default_true_if_probability This variable gives the percentage of time the true branch of a conditional will be taken. It must be greater than or equal to zero and less than or equal to 100. VARIABLE BOOL P1COPT_convert_float_to_double This variable controls the conversion of floats to doubles in expressions. The default in C is to convert all floats to doubles in expressions. This option will allow for the conversion to be turned off. *********************************************************************** PHASE 1 FORTRAN OPTIONS *********************************************************************** VARIABLE BOOL P1FOPT_convert_real_to_double Convert all real*4 data types to real*8 and complex*8 to complex*16. VARIABLE BOOL P1FOPT_debug This variable controls whether debugging information is written to GLOB_info_output_file by the second pass of the Fortran front end. VARIABLE BOOL P1FOPT_expand_format_statements This variable controls how the front end translates formatted io. If true, a formatted read or write is expanded inline into a series of calls to the IO library, one for each formatted item. If false, the format statement is interpreted at runtime by the IO library. VARIABLE BOOL P1FOPT_flush_dummy_args_around_call The front end will arrange to have the dummy arguments modified by a procedure saved prior to calls to other user functions and procedures. In addition, all dummy arguments will be loaded upon return from the called function or subroutine. VARIABLE BOOL P1FOPT_generate_igotos This variable indicates whether IL-1 IGOTO operations should be generated for Fortran computed goto statements and subroutine calls with alternate return specifiers. N.B. This option is temporary. All support will be removed when tags are supported throughout the compiler. VARIABLE BOOL P1FOPT_generate_selects_for_ifs When this option is TRUE, the front end will generate IL-1 SLCT_* operations for logical IF statements of the form IF (test) A SLCT_* operation will be generated only is has no unwanted side-effects, and if the IF statement meets the criteria set by options P1FOPT_select_absolute_cost_ceiling, P1FOPT_select_prob_floor, and P1FOPT_select_adjusted_cost_ceiling. VARIABLE BOOL P1FOPT_inline P1FOPT_inline controls whether automatic inlining is done. VARIABLE INT P1FOPT_inline_max_stats P1FOPT_inline_max_stats sets the maximum number of statements that a routine may have to be inlined. If a routine has more statements than this limit it will not be inlined. VARIABLE INT P1FOPT_inline_max_total_stats P1FOPT_inline_max_total_stats sets the maximum number of statements * total calls that a routine may have to be inlined. If a routine has more statements than this limit it will not be inlined. VARIABLE INT P1FOPT_inline_max_increase P1FOPT_inline_max_increase sets the maximum percent increase that a routine may add to be inlined. The percent increase is computed as follows: increase = 100 * stat_count * call_count / total_stats, stat_count is the number of statements in the routine, call_count is the number of times the routine is called in the file and total_stats is the total number of statements in the file. NOTE: P1FOPT_inline_max_total_stats and P1FOPT_inline_max_increase are or'ed together so P1FOPT_inline_max_increase only affects large files. VARIABLE INT P1FOPT_inline_limit When the user does not explicitly specify a limit for an inline subprogram call, the value of this option is used for that limit. VARIABLE BOOL P1FOPT_inline_unformatted_io This variable contorls how the front end translates unformattd io. If this option is TRUE then unformatted io operations are generated as inline code, if it is FALSE then they are generated as function calls. VARIABLE BOOL P1FOPT_reduce_intrinsics P1FOPT_reduce_intrinsics causes the front end to reduce certain calls to intrinsics with their cheaper algebraic identities. VARIABLE BOOL P1FOPT_rsincos P1FOPT_sincos casues the front end to use the single precision routines for sin and cos. The default is FALSE. VARIABLE BOOL P1FOPT_saveall When this variable is set to TRUE, all Phase 2 packets containing local variables have allocation ALLOC_STATIC. This option allows all local variables to be saved by default, i.e., without the source code specifying a SAVE statement. VARIABLE BOOL P1FOPT_saveall_but_do_variables When this variable is set to TRUE, all Phase 2 packets containing local variables have allocation ALLOC_STATIC except for those variables that are used as do loop control variables. This option allows all local variables to be saved by default, i.e., without the source code specifying a SAVE statement. VARIABLE INT P1FOPT_select_absolute_cost_ceiling The front end will try to generate an IL-1 SLCT_* operation for a logical IF statement of the form IF (test) if the estimated cost of does not exceed this ceiling, without regard to the branch probability associated with the IF statement. VARIABLE INT P1FOPT_select_prob_floor The front end will try to generate an IL-1 SLCT_* operation for a logical IF statement of the form IF (test) if the branch probability for the logical IF is not less than this probability, without regard to the cost of . The probability is expressed as an integer in the range 0...100. VARIABLE INT P1FOPT_select_adjusted_cost_ceiling The front end will try to generate an IL-1 SLCT_* operation for a logical IF statement of the form IF (test) if the adjusted cost of is below this ceiling. The adjusted cost is computed by multiplying the branch probability of the "false" branch of the logical IF statement times the cost of . VARIABLE INT P1FOPT_short_branch_max_stats The short branch heuristic will be applied to subroutines with a number less than this number of executable FORTRAN statements. If set to -1 there is no limit. VARIABLE BOOL P1FOPT_sqrt_instruction The front end will generate an IL-1 FSQRT operation for the FORTRAN intrinsic sqrt when this variable is set to TRUE. VARIABLE BOOL P1FOPT_pad_common The front end will pad common blocks so that entities are aligned on the best boundary for their type when this variable is set to TRUE. VARIABLE BOOL P1FOPT_unix The front end will recognize the unix specific extensions to f77 when this variable is set to TRUE. These extensions consist of additional intrinsic functions and special treatment of the '\' character in character constants. VARIABLE BOOL P1FOPT_vms The front end will recognize the vms specific extensions to f77 when this variable is set to TRUE. VARIABLE BOOL P1FOPT_zero_init The front end will initialize all uninitialized packets to zero when this variable is set to TRUE. VARIABLE BOOL P1FOPT_extend_source The front end will extend the range of FORTRAN source text from columns 1 thorugh 72 to columns 1 through 132. VARIABLE INT P1FOPT_inline_s_copy_string_length The front end will attempt to inline copying of strings up to this length. VARIABLE BOOL P1FOPT_lex_ddebug_lines Controls processing by the lexer of lines with 'd' in column 1. *********************************************************************** PHASE 2 OPTIONS *********************************************************************** VARIABLE CHAR *P2OPT_compilation_script This variable points to the Phase 2 compilation script. It should not be changed after it has been set from the command line arguments. VARIABLE BOOL P2OPT_show_major_states This variable indicates whether a transcript of the major Phase 2 state transitions should be produced. This only includes the states which correspond to the Phase 3 interface transitions, i.e., inlines and module escapes are not shown. It may be changed at any time. VARIABLE BOOL P2OPT_show_module_symtab VARIABLE BOOL P2OPT_show_routine_symtab_pre_phase2 VARIABLE BOOL P2OPT_show_routine_symtab_pre_phase3 VARIABLE BOOL P2OPT_show_routine_symtab_post_phase3 These variables determine when the symbol table should be dumped (for debugging purposes). They may be changed at any time. VARIABLE BOOL P2OPT_show_graph_pre_phase2 VARIABLE BOOL P2OPT_show_graph_pre_phase3 VARIABLE BOOL P2OPT_show_graph_post_phase3 These variables determine when the flow graph should be dumped (for debugging purposes). They may be changed at any time. VARIABLE BOOL P2OPT_show_dependent_invocations This variable indicates whether a transcript of dependent function invocations should be produced. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_short_temp_names This variable indicates whether short temp names should be used by the human-readable format routines in the symbol table. It may be changed at any time. VARIABLE BOOL P2OPT_star_nonprinting_oper_parts This variable indicates whether nonprinting oper parts should be shown as asterisks, as opposed to being left invisible, by the operation formatting code. It may be changed at any time. VARIABLE BOOL P2OPT_verify_module_symtab VARIABLE BOOL P2OPT_verify_routine_symtab_pre_phase2 VARIABLE BOOL P2OPT_verify_routine_symtab_pre_phase3 VARIABLE BOOL P2OPT_verify_routine_symtab_post_phase3 These variables determine when the symbol table should be verified for internal consistency. They may be changed at any time. VARIABLE BOOL P2OPT_verify_graph_pre_phase2 VARIABLE BOOL P2OPT_verify_graph_pre_phase3 VARIABLE BOOL P2OPT_verify_graph_post_phase3 These variables determine when the flow graph should be verified for internal consistency. They may be changed at any time. VARIABLE ALLOC P2OPT_arg_block_alloc This variable gives the allocation to use for argument blocks. It must be either ALLOC_ESTATIC or ALLOC_AUTO. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_share_arg_blocks This variable indicates whether argument blocks may be shared by the calls in a routine, as opposed to allocating a private argument block for each call which needs one. It should only be changed outside of the module level. VARIABLE ALLOC P2OPT_local_parg_copy_alloc This variable gives the allocation to use for local copies of formal arguments. During the expansion of entry operations, local variables are created for each argument which is passed, partly or entirely, in registers. Ideally these local copies will be eliminated during the course of optimization, although this may not always be possible. It must be either ALLOC_ESTATIC or ALLOC_AUTO. It should only be changed outside of the module level. VARIABLE ALLOC P2OPT_ret_block_alloc This variable gives the allocation to use for return value blocks. It must be either ALLOC_ESTATIC or ALLOC_AUTO. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_share_ret_blocks This variable indicates whether return value blocks may be shared by the calls in a routine, as opposed to allocating a private return value block for each call which needs one. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_unscoped_pack_ptr_refs VARIABLE BOOL P2OPT_unscoped_entry_args_mem_pack_ptr_refs These variables indicate what assumptions can be made about pointer references. If TRUE, it is assumed that if the address of any variable in a non-template packet is taken, then the address of any other variable in the packet may be derived from that pointer. If FALSE, it is assumed that if the address of any variable in a non-template packet is taken, then the only other addresses which may be derived from that pointer are of variables which are descendents of the variable whose address was taken. The distinction between the two options is that the first one applies to all non-template variables whose address is taken, except for variables which are used to access arguments for an entry whose arg_loc operator part is ARGS_MEM, in which case the second option applies. In other words, if the entry_args_mem patt field is set, the second option is used, otherwise the first option is used. The intent is to be able to handle argument blocks safely for varargs routines without having to weaken the assumptions made about other packets. These options do not apply to template packets, since template packets can only be used to derive new addresses from existing addresses, subject to the restrictions imposed on the existing addresses. Therefore, the values of these variables do not alter what may be done to storage which does not come from a non-template packet, e.g., dynamically allocated storage. They should only be changed outside of the module level. VARIABLE BOOL P2OPT_suppress_unreferenced_externs This variable indicates whether unreferenced externals should be imported (i.e., unreferenced external packets or unreferenced external routines). It should only be changed outside of the module level. VARIABLE BOOL P2OPT_suppress_unreferenced_locals This variable indicates whether unreferenced locals should be allocated (i.e., unreferenced local packets). It should only be changed outside of the module level. VARIABLE BOOL P2OPT_emit_import_comments This variable indicates whether comments indicating which external names are to be imported (i.e., names which are expected to be exported from another module) should be included in the assembly file. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_emit_proc_addr_taken_info This variable indicates whether assembler directives indicating which procedure entries may possibly be used in an indirect function call should be included in the assembly file. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_emit_arg_stab_type_info This variable indicates whether symbols defining the stab types of formal arguments should be defined in the assembly file (this is needed for dbx). It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_retain_local_packet_names This variable indicates whether local packet names should be retained in the object file, as opposed to being temporary names which are discarded by the assembler. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_define_var_names This variable indicates whether variable names should be defined in the assembly file. Regardless of the value of this option, variable names are not retained in the object file. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_suppress_phase3 This variable indicates whether Phase 2 should suppress Phase 3 of the compilation (for testing and debugging purposes). It must be TRUE for normal compilation. It should not be changed after it has been set from the command line arguments. VARIABLE BOOL P2OPT_compute_address_taken This variable indicates whether Phase 2 should compute information about which variables have had their address taken. If TRUE, this information is computed once for each routine and is used by various Phase 2 optimizations. It should only be changed outside of the module level. VARIABLE BOOL P2OPT_use_intermediate_memory_ops This variable indicates whether the IL-1 memory operation expansions should generate internal Phase 2 intermediate memory operations for array references for use by the disambiguator. The Phase 2 intermediate memory operation expansions, if subsequently invoked, will replace these intermediate operations with the exported IL-2 memory operations. This variable is ignored if memory ops are not being expanded (although this should not be the case for normal compilation). It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_load_constants This variable indicates whether constant operands should be explicitly loaded by the IL-2 expansions when they appear as operands in a position where an immediate with that value cannot be used. This variable is ignored if the final IL-2 expansions are not performed (although this should not be the case for normal compilation). It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_combine_64_bit_constants This variable indicates whether 64-bit constants may appear as operands in IL-2 operations (subject to P2OPT_load_constants) or whether they must be explicitly generated in the IL-2 with COMB operations. This variable is ignored if the final IL-2 expansions are not performed (although this should not be the case for normal compilation). It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_cse_merge_cos_sin_intrinsics VARIABLE BOOL P2OPT_cse_merge_cosf_sinf_intrinsics These variables indicate whether CSE should attempt to merge references to the intrinsic functions cos(f) and sin(f) into references to cos(f)_sin(f) (when they have the same argument). These variables are ignored if CSE is not invoked to coalesce intrinsic functions. These variables should only be changed outside of the routine level. VARIABLE INT P2OPT_cse_max_atan_vector_intrinsic VARIABLE INT P2OPT_cse_max_atanf_vector_intrinsic VARIABLE INT P2OPT_cse_max_atan2_vector_intrinsic VARIABLE INT P2OPT_cse_max_atan2f_vector_intrinsic VARIABLE INT P2OPT_cse_max_cos_vector_intrinsic VARIABLE INT P2OPT_cse_max_cosf_vector_intrinsic VARIABLE INT P2OPT_cse_max_cos_sin_vector_intrinsic VARIABLE INT P2OPT_cse_max_cosf_sinf_vector_intrinsic VARIABLE INT P2OPT_cse_max_exp_vector_intrinsic VARIABLE INT P2OPT_cse_max_expf_vector_intrinsic VARIABLE INT P2OPT_cse_max_log_vector_intrinsic VARIABLE INT P2OPT_cse_max_logf_vector_intrinsic VARIABLE INT P2OPT_cse_max_pow_vector_intrinsic VARIABLE INT P2OPT_cse_max_powf_vector_intrinsic VARIABLE INT P2OPT_cse_max_pow_di_val_vector_intrinsic VARIABLE INT P2OPT_cse_max_pow_ri_val_vector_intrinsic VARIABLE INT P2OPT_cse_max_sin_vector_intrinsic VARIABLE INT P2OPT_cse_max_sinf_vector_intrinsic These variables give the maximum widths of the n-at-a-time vector intrinsics which CSE will introduce into a routine while attempting to replace multiple intrinsic function references with single references to n-at-a-time versions of the same functions. A value of 1 indicates that no such substitutions should be performed for the corresponding class of functions. These variables are ignored if CSE is not invoked to coalesce intrinsic functions. These variables should only be changed outside of the routine level. VARIABLE BOOL P2OPT_aag_require_known_init_for_iv This variable indicates whether the limited class of induction variables for which initial value assertions will be generated should be required to have known initial values. VARIABLE INT P2OPT_aag_iv_init_limit This variable gives a limit for the initial values of induction variables about which initial value assertions will be generated. Increasing induction variables must be initialized to a value which is less than or equal to this limit; decreasing induction variables must be initialized to a value which is greater than or equal to the negation of this limit. This variable is ignored if assertions are not being automatically generated or if P2OPT_aag_require_known_init_for_iv is FALSE. VARIABLE INT P2OPT_aag_iv_increment_limit This variable gives a limit for the increments of induction variables about which initial value assertions will be generated. Each increment of an increasing induction variable must be greater than or equal to zero and less than or equal to this limit; each decrement of a decreasing induction variable must be less than or equal to zero and greater than or equal to this limit. This variable is ignored if assertions are not being automatically generated. VARIABLE INT P2OPT_unroll_first_amount_floor VARIABLE INT P2OPT_unroll_first_amount_ceiling These variables give lower and upper limits on the number of times a loop will be unrolled on its first unrolling. If the total unroll amount computed for the first unrolling is less than or equal to P2OPT_unroll_first_amount_ceiling then it is simply unrolled by that amount (even if it is less than P2OPT_unroll_first_amount_floor). Otherwise an amount will be used between P2OPT_unroll_first_amount_floor and P2OPT_unroll_first_amount_ceiling, inclusive. The amount is chosen in an attempt to minimize the difference between the actual unroll amount (the total amount resulting after the last unrolling) and the desired unroll amount. This feature is disabled if both P2OPT_unroll_first_amount_floor and P2OPT_unroll_first_amount_ceiling are -1. Otherwise they must both be strictly greater than 0, and P2OPT_unroll_first_amount_floor must be less than or equal to P2OPT_unroll_first_amount_ceiling. These variables are ignored if loop unrolling is not being performed. They should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_amount_desired This variable gives an upper limit on the desired number of times a loop will be unrolled. A value of -1 disables this limit. Note that an unrolled loop may have more copies of its body than the amount given by this option, since the granularity of loop unrollings is imperfect when they are performed more than once on a given loop. This option is used to compute a desired amount only. The actual amount will be as close to the computed desired amount as possible without exceeding any of the absolute ceilings (given by other options). This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_fadd_amount_desired VARIABLE INT P2OPT_unroll_fmul_amount_desired VARIABLE INT P2OPT_unroll_gc_amount_desired VARIABLE INT P2OPT_unroll_flop_amount_desired VARIABLE INT P2OPT_unroll_intop_amount_desired VARIABLE INT P2OPT_unroll_mem_ref_amount_desired These variables give upper limits on the desired number of resource uses in various classes in an unrolled loop. Note that a resource use corresponds to how long it takes before that particular resource may be reused, not how long it takes for a result produced by that resource to become available. The first three options are ignored unless GLOB_machine_type is GLOB_MACHINE_TYPE_SATURN. They correspond to cycles (not beats) of floating adder, floating multiplier, and gc (used for floating square roots) resources. P2OPT_unroll_flop_amount_desired is ignored unless GLOB_machine_type is GLOB_MACHINE_TYPE_JANUS. It corrsponds to cycles (not beats) of floating unit resources. P2OPT_unroll_intop_amount_desired corresponds to beats (not cycles) of integer unit resources. P2OPT_unroll_mem_ref_amount_desired corresponds to beats (not cycles) of memory reference resources. Note that a memory reference uses both a beat of integer unit resource and a beat of memory reference resource. A value of -1 disables any given limit. Note that an unrolled loop may have more copies of its body than the amounts given by these options, since the granularity of loop unrollings is imperfect when they are performed more than once on a given loop. These options are used to compute a desired amount only. The actual amount will be as close to the computed desired amount as possible without exceeding any of the absolute ceilings (given by other options). These variables are ignored if loop unrolling is not being performed. They should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_amount_ceiling This variable gives an upper limit on the number of times a loop will be unrolled. An unrolled loop will never have more copies of its body than the amount given by this option (unless adjusted by P2OPT_unroll_eliminate_margin). A value of -1 disables this ceiling. This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_stat_count_ceiling This variable gives an upper limit on the number of stats an unrolled loop may contain. The number of times a loop is unrolled will always be reduced until the unrolled loop will contain no more stats than the number specified by this option (unless adjusted by P2OPT_unroll_eliminate_margin). A value of -1 disables this ceiling. This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_branch_count_ceiling This variable gives an upper limit on the number of internal branch stats (i.e., not loop exits) an unrolled loop may contain. The number of times a loop is unrolled will always be reduced until the unrolled loop will contain no more internal branch stats than the number specified by this option (unless adjusted by P2OPT_unroll_eliminate_margin). A value of -1 disables this ceiling. This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_call_count_ceiling This variable gives an upper limit on the number of call stats an unrolled loop may contain. The number of times a loop is unrolled will always be reduced until the unrolled loop will contain no more call stats than the number specified by this option (unless adjusted by P2OPT_unroll_eliminate_margin). A value of -1 disables this ceiling. This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_eliminate_margin This variable gives an amount to adjust the loop unroll ceilings by if it can be determined that the loop has a constant or bounded trip count and can be eliminated entirely by unrolling it enough times. If a loop can be unrolled enough to eliminate the loop without violating the adjusted ceilings, it will do so. Otherwise the non-adjusted ceilings are used. A ceiling is adjusted by multiplying its value by the value of this option and then dividing by 100. It doesn't make much sense for this option to have a value which is less than 100. This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_unroll_require_call_free_path This variable, when TRUE, constrains loops to have at least one path through them which doesn't contain a call before they're considered for loop unrolling. This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_unroll_delete_dead_loop_exits This variable indicates whether dead loop exits which involve simple induction variable comparisons should be deleted from unrolled loops. If TRUE, dead loop exits are deleted. If FALSE, dead loop exists are retained in the loop unless the loop is eliminated by the unrolling. This variable is ignored if loop unrolling is not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_desired_precondition_amount This variable gives a lower limit on the desired level of preconditioning for a loop. In the absence of a loop-specific precondition amount, innermost reducible quasi loops on which preconditioning is a useful optimization will be preconditioned to the computed desired amount during the first unrolling (although the actual amount of preconditioning may be lower depending on how much the loop is unrolled). A value of -1 disables this default amount (i.e., it is equivalent to no preconditioning). This variable is ignored if loop preconditioning is not being performed by loop unrolling. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_unroll_auto_precondition_loops This variable indicates whether the compiler should make an effort to automatically determine appropriate loop precondition amounts. In the absence of a loop-specific precondition amount, innermost reducible quasi loops on which preconditioning is a useful optimization will be preconditioned to the computed desired amount during the first unrolling (although the actual amount of preconditioning may be lower depending on how much the loop is unrolled). Since preconditioning is a dangerous optimization (there are instances in which the modified exit tests may be incorrect, due to integer overflow), automatic preconditioning should be used carefully, particularly on C code. This variable is ignored if loop preconditioning is not being performed by loop unrolling. It should only be changed outside of the routine level. VARIABLE INT P2OPT_unroll_max_auto_precondition_amount This variable places an upper limit on the amount of preconditioning that the compiler automatically determines when P2OPT_unroll_auto_precondition_loops is TRUE. Note, however, that it does not necessarily place an upper limit on the final computed desired amount (i.e., it only limits that one factor in the desired amount computation). A value of -1 disables this limit. This variable is ignored unless loop preconditioning is being performed by loop unrolling and P2OPT_unroll_auto_precondition_loops is TRUE. It should only be changed outside of the routine level. VARIABLE INT P2OPT_reduc_ideal_f64_add_interleave VARIABLE INT P2OPT_reduc_ideal_f32_add_interleave VARIABLE INT P2OPT_reduc_ideal_int_add_interleave VARIABLE INT P2OPT_reduc_ideal_f64_mul_interleave VARIABLE INT P2OPT_reduc_ideal_f32_mul_interleave VARIABLE INT P2OPT_reduc_ideal_int_mul_interleave VARIABLE INT P2OPT_reduc_ideal_bool_interleave VARIABLE INT P2OPT_reduc_ideal_bit_interleave VARIABLE INT P2OPT_reduc_ideal_f64_min_max_interleave VARIABLE INT P2OPT_reduc_ideal_f32_min_max_interleave VARIABLE INT P2OPT_reduc_ideal_int_min_max_interleave VARIABLE INT P2OPT_reduc_ideal_f64_parasite_interleave VARIABLE INT P2OPT_reduc_ideal_f32_parasite_interleave VARIABLE INT P2OPT_reduc_ideal_int_parasite_interleave These variables give the ideal interleavings for the various types of reductions. A value of 1 indicates that reductions of that type should not be performed by default. These options are ignored if reductions are not being performed. They should only be changed outside of the routine level. VARIABLE INT P2OPT_reduc_max_interleave_overshoot This variable gives a maximum amount to adjust reduction interleavings by in order to make them be exact factors of the number of components in the reduction after the associated loop unrolling has taken place. This limit is a percentage of the ideal interleaving, so the actual limit is obtained by multiplying the ideal interleaving by the value of this option, then dividing by 100. It doesn't make much sense for this option to have a value which is less than 100. This variable is ignored if reductions are not being performed. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_reduc_require_known_init_for_counters This variable indicates whether the counters used for parasitic reductions should be required to be initialized with constant values in the pre-header, which can then be subjected to the limit given by P2OPT_reduc_counter_init_limit. This variable is ignored if reductions are not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_reduc_counter_init_limit This variable gives a limit for the initial values of counters used for parasitic reductions. Increasing counters must be initialized to a value which is less than or equal to this limit. Decreasing counters must be initialized to a value which is greater than or equal to the negation of this limit. This variable is ignored if reductions are not being performed or if P2OPT_reduc_require_known_init_for_counters is FALSE. It should only be changed outside of the routine level. VARIABLE INT P2OPT_reduc_counter_increment_limit This variable gives a limit for the increments of counters used for parasitic reductions. Each increment of an increasing counter must be greater than zero and less than or equal to this limit. Each increment of a decreasing counter must be less than zero and greater than or equal to the negation of this limit. This variable is ignored if reductions are not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_sel_cost_ceiling This variable gives the maximum operation cost for operations which are to be moved above splits when an IF is transformed into a SELECT. A value of -1 disables this ceiling (although operations which are given infinite cost will still prevent the transformation from taking place). This variable is ignored if the optimization which transforms IFs into SELECTs is not being performed. It should only be changed outside of the routine level. VARIABLE INT P2OPT_sel_assign_cost VARIABLE INT P2OPT_sel_load_cost VARIABLE INT P2OPT_sel_fdiv_cost VARIABLE INT P2OPT_sel_fsqrt_cost VARIABLE INT P2OPT_sel_default_floating_cost VARIABLE INT P2OPT_sel_imul_cost VARIABLE INT P2OPT_sel_idiv_cost VARIABLE INT P2OPT_sel_default_integer_cost VARIABLE INT P2OPT_sel_select_cost These variables give the costs for the various types of operations which might be moved above a split when an IF is transformed into a SELECT. A value of -1 indicates infinite cost, and prevents such operations from being moved above splits. Note that P2OPT_sel_select_cost refers to the cost of the select portion of a select operation only; the portion of the operation which is used to compute operation. These variables are ignored if the optimization which transforms IFs into SELECTs is not being performed. They should only be changed outside of the routine level. VARIABLE BOOL P2OPT_replace_induction_memory_references This variable indicates whether memory references involving induction variables may be rewritten to use other induction variables. This variable is ignored if induction variable simplification is not being performed. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_replace_induction_comparisons This variable indicates whether comparisons involving induction variables may be rewritten to use other induction variables. This runs a risk of changing the behavior of comparisons whose new induction variables overflow where the original ones didn't. This variable is ignored if induction variable simplification is not being performed. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_replace_unsigned_induction_comparisons This variable indicates whether unsigned comparisons involving induction variables may be converted to signed comparisons and rewritten to use other induction variables. This runs a risk of changing the behavior of comparisons whose new induction variables overflow where the original ones didn't. This variable is ignored if induction variable simplification is not being performed or if P2OPT_replace_induction_comparisons is FALSE. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_use_scaled_induction_comparison_replacements This variable indicates whether comparisons involving induction variables may be rewritten to use scaled versions of the original induction variable. This runs a risk of changing the behavior of comparisons whose new induction variables overflow where the original ones didn't. This variable is ignored if induction variable simplification is not being performed or if P2OPT_replace_induction_comparisons is FALSE. It should only be changed outside of the routine level. VARIABLE INT P2OPT_de_max_term_size This variable indicates the maximum number of factors a term in a diophantine expression may contain. The diophantine expression package is used by various optimization modules in Phase 2, and in the disambiguator. It should only be changed outside of the routine level. VARIABLE INT P2OPT_de_max_sum_size This variable indicates the maximum number of terms a sum in a diophantine expression may contain. The diophantine expression package is used by various optimization modules in Phase 2, and in the disambiguator. It should only be changed outside of the routine level. VARIABLE BOOL P2OPT_compute_dominators This variable indicates whether Phase 2 should compute dominator set information prior to invoking PHASE3_Routine_End (immediate dominator information is not computed). The dominator functions in the phase23 module should not be used by Phase 3 unless dominator information has first been computed by Phase 2. This variable should only be changed outside of the routine level. VARIABLE BOOL P2OPT_compute_live_temps This variable indicates whether Phase 2 should compute live temp information prior to invoking PHASE3_Routine_End. The live temp functions in the phase23 module should not be used by Phase 3 unless live temp information has first been computed by Phase 2. This variable should only be changed outside of the routine level. VARIABLE BOOL P2OPT_use_ivdep This variable indicates whether the disambiguator should consider whether the user has directed that a loop contains no vector hazards in analyzing location conflicts. This variable should be changed only outside of the routine level. VARIABLE BOOL P2OPT_ivdep_all_loops This variable indicates that the disambiguator should behave as if all quasi loops (including compiler generated loops) had directives indicating that they contain no vector hazards. This variable will be ignored if P2OPT_use_ivdep is FALSE. It should be changed only outside of the routine level. ========================================================================= PHASE 3 OPTIONS ========================================================================= VARIABLE BOOL P3OPT_trace_schedule A boolean flag. If true, the trace scheduler is called in Phase3. If false, Phase3 is essentially a no-op. VARIABLE BOOL P3OPT_compact A boolean flag. If true, the code generator will generate compact code. If false, the code generator will schedule operations sequentially, in the order they appear on the trace, such that no two operations in the schedule will execute concurrently. VARIABLE BOOL P3OPT_x_mode A boolean flag. When this is set it enables a number of experimental code generator heuristics that are intended to produce better code for very parallel traces. VARIABLE TS_TRACE_PICKER_HEURISTIC P3OPT_trace_picker_heuristic This variable selects the trace picking heuristic. See ts/trace_picker.H for a list of alternatives. VARIABLE TS_EXPECT_HEURISTIC P3OPT_expect_heuristic This variable selects the expect heuristic. See ts/expect for a list of alternatives. VARIABLE BOOL P3OPT_generate_trap_code This variable selects whether the compiler generates user state code or (privileged) trap code. When set, this option changes the selected machine model, eliminating some register files. If the code contains operations that may require use of an eliminated register file, the compilation will diverge (hence it may be useful to specify P3OPT_max_schedule_length, defined below, when setting this option). This option may not be changed after the first invocation of the code generator. VARIABLE INT P3OPT_unspecified_if_prob An integer value. It represents the probability of the TRUE successor of an IF, in the case where the branch probability has been left unspecified by the front end. The probability is scaled by 100; 50 means a .5 probability. VARIABLE BOOL P3OPT_bus_card_disambiguate_above_splits If true, the unsafe optimization of of bus and card disambiguating above splits is performed. This allows us to experiment with 14 and 28 wide code. This is a temporary option and will go away when the compiler can do this safely. The traces affected by this option are limited by P3OPT_bus_card_disambiguate_above_splits_limit. VARIABLE BOOL P3OPT_bus_card_disambiguate_above_splits_on_loop_trace If true, the unsafe optimization of of bus and card disambiguating above splits is performed on the main trace of an inner loop. The traces affected by this option are limited by P3OPT_bus_card_disambiguate_above_splits_limit. VARIABLE INT P3OPT_bus_card_disambiguate_above_splits_trace_limit The bus_card disambiguation will only be applied to the first "limit" traces. If set to -1, there is no limit. VARIABLE CG_BANK_STALL_HEURISTIC P3OPT_bank_stall_heuristic This variable selects the heuristic for memory bank stalls. Possible values are: CG_NO_STALLS - Don`t allow code that may bank stall. CG_FILL_GAPS - Allow code that may bank stall if the machine would otherwise be idle. CG_ALLOW_STALLS - Do no work to avoid bank stalls. For hardware debugging and comparison only. VARIABLE INT P3OPT_bank_stall_threshold This variable sets the threshold (in beats) after which a memory operation will not be delayed because of a potential bank stall. This has the effect that a higher-priority but possibly bank- stalling memory reference will be preferred over a lower-priority memory reference that is known not to bank stall. The count is reset whenever a memory reference is scheduled that may cause a bank stall. VARIABLE INT P3OPT_bank_stall_operation_skip_limit Limits the number of higher priority memory operations the code generator is willing to skip in order to find a bank stall safe memory reference to schedule. VARIABLE INT P3OPT_bank_stall_load_skip_limit Limits the number of higher priority loads the code generator is willing to skip in order to find a bank stall safe memory reference to schedule. VARIABLE INT P3OPT_bank_stall_store_skip_limit Limits the number of stores that must be data ready before a bank stall will be risked on behalf of a store. A bank stall will be risked on behalf of a store if and only if there are more data ready stores than this limit, or if there are no data ready load operations. VARIABLE BOOL P3OPT_bug_cluster If TRUE attempt to keep all the members of a component on the same logical hardware component. (Ignored unless P3OPT_x_mode is TRUE.) VARIABLE BOOL P3OPT_bug_cluster_loads If TRUE loads are "clustered" onto logical hardware components. This means that if we can guess the target of load we will never allow the load to take the last register write port. (Default TRUE, should be false for Saturn.) (Ignored unless P3OPT_x_mode and P3OPT_bug_cluster are TRUE.) VARIABLE BOOL P3OPT_list_scheduler_cluster_loads IF TRUE loads are "clustered" in the list scheduler. This means that a load that targets a floating register bank will never take the last register write port. (Default TRUE, should be false for Saturn.) (Ignored unless P3OPT_x_mode is TRUE.) VARIABLE BOOL P3OPT_bug_cluster_cse_loads_equate_components If TRUE components are equated (put into the same equivalence class) when the same load is a read by both components. (Ignored unless P3OPT_x_mode and P3OPT_bug_cluster are TRUE.) VARIABLE INT P3OPT_inter_cluster_move_penalty When bug-clustering is turned on, this gives a penalty in number of beats that bug will endure in order to schedule an operation in its component's logical hardware cluster. VARIABLE INT P3OPT_clustering_granularity Gives the number of components that share a CSE that will be clustered together before a new hardware logical cluster is forced if the other clusters are underutilized. VARIABLE BOOL P3OPT_add_greed_control_edges Tells the code generator to run its greed control adding algorithm. (Ignored unless P3OPT_x_mode is TRUE.) VARIABLE BOOL P3OPT_greed_control_loads Controls whether loads are considered by the greed control algorithm. (Ignored unless P3OPT_add_greed_control_edges and P3OPT_x_mode are TRUE.) VARIABLE BOOL P3OPT_lower_store_priority_in_loop_traces Controls the lowering of the priority for stores of height 0 in loop traces. VARIABLE BOOL P3OPT_node_split_for_register_allocation Tells the code generator to use node splitting to deallocate registers instead of spilling. (Ignored unless P3OPT_x_mode is TRUE.) VARIABLE BOOL P3OPT_node_split_for_write_resources Tells the code generator to use node splitting to reallocate register write resources from earlier scheduled lower priority operations to later scheduled higher priority ones when possible. (Ignored unless P3OPT_x_mode is TRUE.) VARIABLE BOOL P3OPT_node_split_for_register_transfers Tells the code generator to use node splitting instead of floating BORs. (Ignored unless P3OPT_x_mode is TRUE.) VARIABLE BOOL P3OPT_pair_mode The code generator will try to issue paired operations for loop traces if this option is TRUE. VARIABLE BOOL P3OPT_allow_motion_below_splits The code generator will allow operations to move below splits only if the value of this variable is TRUE. VARIABLE BOOL P3OPT_stores_constrain_splits If P3OPT_allow_motion_below_splits is FALSE, this controls whether stores are given special treatment and allowed to move below splits. VARIABLE BOOL P3OPT_allow_motion_below_loop_exits The code generator will allow operations to move below loop_exits only if the value of this variable is TRUE. VARIABLE BOOL P3OPT_stores_constrain_loop_exits If P3OPT_allow_motion_below_loop_exits is FALSE, this controls whether stores are given special treatment and allowed to move below loop exits. VARIABLE BOOL P3OPT_allow_dismissable_loads If P3OPT_allow_dismissable_loads is FALSE, the code generator will not allow loads to move above splits, ie, no dismissable loads will be generated. VARIABLE BOOL P3OPT_force_caller_saves If P3OPT_force_caller_saves is TRUE, the code generator will ignore the register save information for calls and treat it as if it were caller_saves. VARIABLE BOOL P3OPT_use_location_disambiguation A boolean flag. If true, the code generator will call the disambiguator to determine if two memory references can be to the not necessary in that mode. This option should only be true if the disambiguator has been properly initialized by Phase 2. VARIABLE BOOL P3OPT_use_resource_disambiguation A boolean flag. If true, the code generator will call the disambiguator to determine if two memory references can use the same memory bank, card, or bus. If false, the code generator will always assume that they may use some mutually exclusive memory resource. This option should only be true if the disambiguator has been properly initialized by Phase 2. This option is completely independent of P3OPT_compact. VARIABLE BOOL P3OPT_use_short_branches If true, the code generator will only reserve the resources required for a short (16-bit) branch address for any branch, regardless of whether the branch target lies within this range. This may result in an assembler and/or loader error complaining about a branch target being out of reach. The traces affected by this option are limited by P3OPT_short_branch_trace_number_limit. VARIABLE BOOL P3OPT_use_short_branches_for_loop_exits If true, the code generator will only reserve the resources required for a short (16-bit) branch address for loop exits, regardless of whether the branch target lies within this range. This may result in an assembler and/or loader error complaining about a branch target being out of reach. This option is only applied to the main trace of an inner loop. The traces affected by this option are limited by P3OPT_short_branch_trace_number_limit. VARIABLE INT P3OPT_short_branch_trace_limit The short branch heuristics will only be applied to the first "limit" traces. If set to -1, there is no limit. VARIABLE INT P3OPT_short_branch_loop_aregion_instr_threshold If short branches are used for loop exits, the trace scheduler may attempt to split the loop exit allocation regions to allow the short branches to reach their targets. It does so when the allocation region for the loop has more than this number of instructions and more than 'P3OPT_short_branch_loop_aregion_exit_threshold' exits. VARIABLE INT P3OPT_short_branch_loop_aregion_exit_threshold If short branches are used for loop exits, the trace scheduler may attempt to split the loop exit allocation regions to allow the short branches to reach their targets. It does so when the allocation region for the loop has more than this number of exits and more than 'P3OPT_short_branch_loop_aregion_instr_threshold' instructions. VARIABLE INT P3OPT_short_branch_loop_exit_aregion_tail_limit If the trace scheduler is splitting loop exit allocation regions to allow short branches used for loop exits to reach their targets, a loop exit allocation region will be split at the first MI which is goto-compatible only if there are at least this number of MI's following the goto-compatible MI in the allocation region. VARIABLE BOOL P3OPT_delay_for_free_register If true, a spill will be generated only if there is no enqueued VN that can be known to free a register when it is scheduled. The test for this is currently a little crude (though safe) in that it won't detect some situations in which it can delay. See cg/spill.C. VARIABLE BOOL P3OPT_requeue_for_register Requeues operations that fail to get registers instead of constraining them by some reader of an operation in the appropriate register bank. VARIABLE BOOL P3OPT_emit_mi_mapping. A boolean flag. If true, a mapping from the instructions back to the schedules, aregions, and MIs is emitted as comments in the assembly language text. VARIABLE BOOL P3OPT_generate_multibeat_nops A boolean flag. If true, sequences of instructions that are nops are collapsed into multibeat nops whenever possible. VARIABLE BOOL P3OPT_generate_partial_schedule_for_fall_through_split A boolean flag. If true a split partial schedule is created for the fall through edge if falling through to uncompacted code. VARIABLE INT P3OPT_additional_partial_schedule_join_length An integer value. The number of cycles of additional partial schedule information for a join partial schedule. This gives an upper bound on the number of cycles that can be deleted from a schedule when falling through to compacted code. VARIABLE INT P3OPT_max_copy_ratio An integer value. This ratio is used to trigger a change in the trace picking heuristic to avoid exponential copying. The ratio is scaled by 100. If S is the number of STATs in a routine at the end of Phase2, and C is the number of compensation copies generated for the routine, then when the following is true C > (P3OPT_max_copy_ratio * S )/100 the trace picking heuristic is changed to TS_NO_COMPENSATION to avoid further copying. VARIABLE INT P3OPT_max_trace_length An integer value. The maximum length of a trace. VARIABLE INT P3OPT_max_schedule_length An integer value. The maximum length of a schedule, ie, the maximum number of instructions allowed for a single trace. VARIABLE INT P3OPT_max_calls_per_trace An integer value. The maximum number of call operations in a single trace. VARIABLE BOOL P3OPT_emit_trace_labels A boolean flag. If true, the trace scheduler will emit a trace label at the start of each trace, for use by the profiler. VARIABLE BOOL P3OPT_emit_asm_debug_info A boolean flag. If true, information useful to the assembly language debugger will be listed in the assembly file. VARIABLE BOOL P3OPT_cross_jump A boolean flag. If true, cross-jumping will be performed after all code has been generated for a routine, but before any code is emitted. VARIABLE BOOL P3OPT_single_rejoin_dummy A boolean flag. This controls how rejoins are buffered in the bookkeeper. If true, all rejoins to an on-trace mi are buffered with a single dummy. This means there is only one rejoin edge per on-trace mi, and reduces rejoin compensation copies. If false, a distinct dummy is introduced for each rejoin to an on-trace mi. This avoids a cascade of jumps-to-jumps in the generated code. VARIABLE INT P3OPT_rejoin_count_trace_fence An integer count. If P3OPT_single_rejoin_dummy is false and if an mi has more than P3OPT_rejoin_count_trace_fence predecessors, we break the trace. Specifically, the mi will not be on the same trace as any of its predecessors. This prevents any rejoin compensation copies from being placed on these edges. This option is ignored if P3OPT_single_rejoin_dummy is true. VARIABLE BOOL P3OPT_suppress_rejoin_compensation A boolean flag. If true, the bookkeeper does additional analysis for each operation which has moved above a rejoin to the schedule to determine if the compensation copy for that operation may be suppressed. VARIABLE BOOL P3OPT_suppress_rejoin_comp_loops_with_branches A boolean flag. If true, the bookkeeper does additional analysis for each operation which has moved above a rejoin to the schedule generated for a loop trace which has an internal branch to determine if the compensation copy for that operation may be suppressed. VARIABLE BOOL P3OPT_emit_line_numbers If true, the trace scheduler will emit line number stabs to GLOB_as_output_file. VARIABLE BOOL P3OPT_single_line_traces If true, the trace scheduler will make sure every stat in a trace comes from the same source line. This option is independent of the trace picking hueristic. VARIABLE CHAR *P3OPT_preserved_registers Specifies which registers are to be preserved by calls. The format of the option string is a sequence of integers which can be delimited by sequences of any nondigits. The integers are recognized on groups of three and each triple is interpreted so that t1 is the cluster. T2 gives the subbank: integer 0-31 == 0, integer 32-63 == 1, floating 0-31 == 2, floating 32-63 == 3. T3 gives the number of callee saves registers for the named subbank. Debugging options: VARIABLE BOOL P3OPT_verify_pools A boolean flag. If true, pools are verified (using P3MEM_Verify) at strategic locations in Phase3. This option is meaningful only if the compiler is built with POOL_DEBUG set to true. VARIABLE INT P3OPT_show_pool_stats_trace_interval Phase 3 pool statistics are written to GLOB_info_output_file every N traces, where N is the value of this option. If the value is zero, no statistics are written. This option is meaningful only if the compiler is built with POOL_DEBUG set to true. VARIABLE BOOL P3OPT_verify_edge_probs A boolean flag. If true, the edge probabilities in the MI graph are checked for consistency at strategic locations in Phase3. VARIABLE BOOL P3OPT_dump_mis_before_trace_scheduling A boolean flag. If true, the trace scheduler will dump the MI graph it constructs from the Phase2 flow graph, before starting to trace schedule. The graph is dumped to GLOB_info_output_file. VARIABLE BOOL P3OPT_dump_mis_after_trace_scheduling A boolean flag. If true, the trace scheduler will dump the MI graph after trace scheduling is complete, but before the assembly code is emitted. The graph is dumped to GLOB_info_output_file. VARIABLE BOOL P3OPT_ts_debug A boolean flag. If true, trace scheduler debugging information is dumped to GLOB_info_output_file. VARIABLE BOOL P3OPT_cg_debug A boolean flag. If true, code generator debugging information is dumped to GLOB_info_output_file. VARIABLE BOOL P3OPT_ts_split_join_statistics If TRUE, the trace scheduler and code generator will collect and print some statistics about how many cycles are deleted when merging splits and joins on GLOB_info_output_file. VARIABLE BOOL P3OPT_cg_collect_statistics If TRUE, the code generator will collect and print some statistics on GLOB_info_output_file. VARIABLE BOOL P3OPT_cg_print_components If TRUE, the code generator will print the components of each trace in a concise formant on GLOB_info_output_file. Types External variables Copyright (C) 1986 Multiflow Computer, Inc. The information and source code contained herein is the exclusive property of Multiflow Computer, Inc. and may not be disclosed, examined or reproduced in whole or in part without explicit written authorization from the company. Author: Thomas J. Karzes static char sccs_id[] = "@(#)dgopts.H 10.1 10/26/89 13:06:11"; *********************************************************************** PHASE 2 SYMBOL TABLE/FLOW GRAPH DUMPER OPTIONS *********************************************************************** Description: This module defines and exports a number of global variables used by the dump_graph module to control the formatting of the Phase 2 symbol table, flow graph, and related structures. Reserved prefixes: DGOPT for Phase 2 symbol table and flow graph dumping options *********************************************************************** PHASE 2 SYMBOL TABLE DUMPER OPTIONS *********************************************************************** VARIABLE BOOL DGOPT_show_packs If TRUE, packets are dumped. VARIABLE BOOL DGOPT_show_vars If TRUE, variables are dumped. Ignored if DGOPT_show_packs is FALSE. VARIABLE BOOL DGOPT_show_init If TRUE, packet initialization lists are dumped. Ignored if DGOPT_show_packs is FALSE. VARIABLE BOOL DGOPT_show_temps If TRUE, temps are dumped. Ignored when at the module level. VARIABLE BOOL DGOPT_show_ltconsts If TRUE, ltconsts are dumped. VARIABLE BOOL DGOPT_show_rdecls If TRUE, rdecls are dumped. VARIABLE BOOL DGOPT_show_entry_list If TRUE, a list of the numbers of the basic blocks on the basic block entry list is dumped. VARIABLE BOOL DGOPT_show_graph If TRUE, the Phase 2 flow graph is dumped. VARIABLE BOOL DGOPT_show_stats If TRUE, the stats in each basic block are dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_dfo_number If TRUE, the dfo number of each basic block is dumped. This should only be set to TRUE if dfo information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_dfo_parent If TRUE, the dfo parent of each basic block is dumped. This should only be set to TRUE if dfo information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_dominators If TRUE, a list of the numbers of the basic blocks which dominate each basic block is dumped. This should only be set to TRUE if dominator information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_dom_parent If TRUE, the immediate dominator of each basic block is dumped. This should only be set to TRUE if immediate dominator information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_qloop_parent If TRUE, the immediate quasi loop of each basic block is dumped. This should only be set to TRUE if quasi loop information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_live_temps_out If TRUE, a list of the names of the temps which are live on exit from each basic block is dumped. This should only be set to TRUE if live temp information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_rtc_in If TRUE, a list of the temp defs which copy reach the entrance to each basic block is dumped. This should only be set to TRUE if reaching temp copy information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_reaching_tdefs If TRUE, a list of the reaching temp defs associated with each stat is dumped (this switch is ignored if DGOPT_show_stats is FALSE). This should only be set to TRUE if reaching temp def information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_reaching_tuses If TRUE, a list of the reaching temp uses associated with each stat is dumped (this switch is ignored if DGOPT_show_stats is FALSE). This should only be set to TRUE if reaching temp use information is current when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_derivations If true, the derivation for each IL-2 memory reference is dumped. It should only be set to TRUE if derivations have been computed when the flow graph is dumped. Ignored if DGOPT_show_graph is FALSE. VARIABLE BOOL DGOPT_show_assertions If TRUE, the assertion nodes collected by the disambiguator are dumped. This should only be set to TRUE if disambiguation information is current when the flow graph is dumped. VARIABLE BOOL DGOPT_show_deriv_tdefs This variable indicates whether the temp defs used in derivations are still current and hence may be displayed nicely. Ignored if both DGOPT_show_derivations and DGOPT_show_assertions are FALSE. VARIABLE BOOL DGOPT_show_qloops If TRUE, the quasi loop structure of the flow graph is dumped. This should only be set to TRUE if quasi loop information is current when the flow graph is dumped. VARIABLE BOOL DGOPT_show_disambiguation If TRUE, the disambiguation results for every pair of IL-2 memory references is shown. It is intended for use with small programs. This should only be set to TRUE if disambiguation information is current when the flow graph is dumped. VARIABLE BOOL DGOPT_show_pairable_refs If TRUE, all pairs of 32-bit IL-2 memory references that can be paired into single 64-bit memory references are shown. It is intended for use with small programs. This should only be set to TRUE if disambiguation information is current when the flow graph is dumped.