CPU2006 Flag Description
Sun Microsystems SPARC Enterprise T5220 (gccfss)
| Compilers |
Sun Studio 12
- "cc": Sun Studio C
- "CC": Sun Studio C++
- "f90": Sun Studio Fortran
GCC for SPARC Systems V4.2.0 (gccfss).
- "gcc": invoke compiler for C programs
- "g++": invoke compiler for C++ programs.
Note: these compilers are described together because gccfss uses the same optimizing
code generator as Studio 12.
|
| Operating systems: |
Solaris 10 |
| Copyright: |
The text for many of the descriptions below was excerpted from the Sun Studio Compiler
Documentation, which is copyright © 2005 Sun Microsystems, Inc. The original documentation can be found at docs.sun.com.
Some material below is quoted from the gccfss website, http://cooltools.sunsource.net/gcc/. Additional information about GCC
options may be found at the The GNU C documentation website. |
| Last updated: 29-Dec-2007 jh |
Base Compiler Invocation
-
- g++
![[user]](http://www.spec.org/auto/cpu2006/flags/user.png)
- CXX, LD
-
Invoke GCC for SPARC Systems, targetting C++ programs, and automatically adding the C++ library. See
http://cooltools.sunsource.net/gcc/
for more information.
Note: this compiler is sometimes referenced below as "g-plus-plus" due to a limitation in
how SPEC reports flags (it uses the XML name, and under the XML specification, such names are not allowed to use plus signs).
The actual spelling used on the command line is "g++".
Peak Compiler Invocation
-
- g++
- CXX, LD
-
Invoke GCC for SPARC Systems, targetting C++ programs, and automatically adding the C++ library. See
http://cooltools.sunsource.net/gcc/
for more information.
Note: this compiler is sometimes referenced below as "g-plus-plus" due to a limitation in
how SPEC reports flags (it uses the XML name, and under the XML specification, such names are not allowed to use plus signs).
The actual spelling used on the command line is "g++".
Base Optimization Flags
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
Peak Optimization Flags
-
- -xprofile=collect:./feedback
- PASS1_CFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
-
-
-
- -xprofile=collect:./feedback
- PASS1_CFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
-
- -xprofile=collect:./feedback
- PASS1_CFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
-
- -xprofile=collect:./feedback
- PASS1_CFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
-
-
-
- -xprofile=collect:./feedback
- PASS1_CFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
- -xprofile=collect:./feedback
- PASS1_CFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
- -xprofile=collect:./feedback
- PASS1_CXXFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
- -xprofile=collect:./feedback
- PASS1_CXXFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
-
-
- -xprofile=collect:./feedback
- PASS1_CXXFLAGS, PASS1_LDFLAGS
-
Collect profile data for feedback-directed optimization. If an option directory is named, the feedback will be stored
there.
When FDO is used, the training run gathers information regarding execution paths and data values. Hardware performance
counters are not used. FDO improves existing optimizations but does not introduce new classes of optimization.
For gccfss, profile collection works the same as Sun Studio on SPARC.
-
-
-
- -xipo=2
- OPTIMIZE
-
Perform optimizations across all object files in the link step:
- 0 = off
- 1 = on
- 2 = performs whole-program detection and analysis.
At -xipo=2, the compiler performs inter-procedural aliasing analysis as well as optimization of memory allocation and
layout to improve cache performance.
-
-
-
Implicitly Included Flags
This section contains descriptions of flags that were included implicitly
by other flags, but which do not have a permanent home at SPEC.
-
-
- -O3
- gcc,g-plus-plus
-
In addition to the optimizations at -O2:
add automatic inlining of functions in the same file, and
use optmization algorithms that may take significantly more compilation time or that do not have as
high a probability of improving execution time, such as speculative code motion.
- Includes:
-
- -O2
- gcc,g-plus-plus
-
In addition to the optimizations at -O1, add global optimizations at the function level, loop unrolling, and software
pipelining.
- Includes:
-
- -O1
- gcc,g-plus-plus
-
With -O1, also spelled "-O", optimizations include: basic local and global optimizations, such as induction variable
elimination, common subexpression elimination, constant propogation, register allocation, and basic block merging.
-
-
-
-
-
-
-
-
-
-
- -xprefetch_level=2
-
Control the level of searching that the compiler does for prefetch opportunities by setting n to 1, 2, or 3,
where higher numbers mean to do more searching. The default for Sun Studio C and Sun Studio C++ is 1. The default for Sun
Studio Fortran and for gccfss is 2.
-
- -xtarget=native
-
Selects options for architecture, chip timing, and cache sizes. These can also be controlled separately, via
-xarch, -xchip, and -xcache, respectively. A wide variety of targets can be selected, including
ultra3, ultra3cu, ultra3i, ultra3iplus, ultra4, ultra4plus, ultraT1, ultraT2, sparc64vi. In each case, appropriate options
are selected for architecture, chip timing, and cache size to match that target.
If -xtarget=native is selected, options that are appropriate for the system where the compile is being done.
The default is -xtarget=generic, which sets the parameters for the best performance over most 32-bit platform
architectures.
On Solaris SPARC systems, the default pointer size with -xtarget=native is 32-bit.
- Includes:
-
-
- -xcache=...
-
xcache defines the cache properties for use by the optimizer. It can specify
use of default assumptions ("generic"); use of whatever the compiler can assume
about the current platform ("native"); or an explicit description of up to three
levels of cache, using colon-separated specifiers of the form si/li/ai,
where:
- si is the size of the cache, in kb
- li is the line size, in bytes
- ai is the associativity
-
Platform settings
One or more of the following settings may have been applied to the testbed. If so, the "Platform Notes" section of the
report will say so; and you can read below to find out more about what these settings mean.
autoup=<n> (Unix /etc/system)
When the file system flush daemon fsflush runs, it writes to disk all modified file buffers that are more
than n seconds old.
bufhwm=<n> (Unix /etc/system)
Sets the upper limit of the file system buffer cache. The units for bufhwm are in kilobytes.
cpu_bringup_set=<n> (Unix /etc/system)
Specifies which processors are enabled at boot time. <n> represents a bitmap of the
processors to be brought online.
disablecomponent (System Management Services)
This command can be used prior to booting the system for a 1-cpu test. The tester uses disablecomponent to
add all other CPUs to the "blacklist", which is a list of components that cannot be used at boot time.
LD_LIBRARY_PATH=<directories> (linker)
LD_LIBRARY_PATH controls the search order for both the compile-time and run-time linkers. Usually, it can be
defaulted; but testers may sometimes choose to explicitly set it (as documented in the notes in the submission), in order to
ensure that the correct versions of libraries are picked up.
LD_PRELOAD=<shared object> (Unix environment variable)
Adds the named shared object to the runtime environment.
MADV=access_lwp and LD_PRELOAD=madv.so.1 (Unix environment variables)
When the madv.so.1 shared object is present in the LD_PRELOAD list, it is possible to provide advice to the system
about how memory is likely to be accessed. The advice present in MADV applies to all processes and their descendants. A
commonly used value is access_lwp, which means that when memory is allocated, the next process to touch it will be
the primary user. Examples of other possible values include sequential, for memory that is used only once and
then no longer needed and acces_many when many processes will be sharing data.
MPSSHEAP=<size>, MPSSSTACK=<size>, and
LD_PRELOAD=mpss.so.1 (Unix environment variables)
When these variables are set, the mpss.so.1 shared object will set the preferred page size for new processes, and their
descendants, to the requested sizes for the heap and stack.
PARALLEL=<n> (Unix environment variable)
If programs have been compiled with -xautopar, this environment variable can be set to the number of
processors that programs should use.
segmap_percent=<n> (Unix /etc/system)
This value controls the size of the segmap cache as a percent of total memory. Set this value to help keep the file system cache from consuming memory unnecessarily.
STACKSIZE=<n> (Unix environment variable)
Set the size of the stack (temporary storage area) for each slave thread of a multithreaded program.
submit=echo 'pbind -b...' > dobmk; sh dobmk (SPEC tools, Unix shell)
When running multiple copies of benchmarks, the SPEC config file feature submit is sometimes used to
cause individual jobs to be bound to specific processors. If so, the specific command may be found in the config file; here
is a brief guide to understanding that command:
- submit= causes the SPEC tools to use this line when submitting jobs.
- echo ...> dobmk causes the generated commands to be written to a file, namely
dobmk.
- pbind -b causes this copy's processes to be bound to the CPU specified by the expression that
follows it. See the config file used in the submission for the exact syntax, which tends to be cumbersome because of
the need to carefully quote parts of the expression. When all expressions are evaluated, each core ends up with
exactly one copy of each benchmark. The pbind expression may include various elements from the SPEC toolset and from
standard Unix commands, such as:
- $BIND: a reference to a value from the bind line, a line of the form
"bind = n n n n", where each "n" is a processor number. See
http://www.spec.org/cpu2006/docs/config.html#bind
for details on this feature.
- $$: the current process id
- $SPECCOPYNUM: the SPEC tools-assigned number for this copy of the benchmark.
- psrinfo: find out what processors are available
- grep on-line: search the psrinfo output for information regarding on-line cpus
- expr: Calculate simple arithmetic expressions. For example, the effect of binding jobs to a
(quote-resolved) expression such as:
expr ( $SPECCOPYNUM / 4 ) * 8 + ($SPECCOPYNUM % 4 ) )
would be to send the jobs to processors whose numbers are:
0,1,2,3, 8,9,10,11, 16,17,18,19 ...
- awk...print \$1: Pick out the line corresponding to this copy of the benchmark and use the CPU
number mentioned at the start of this line.
- sh dobmk actually runs the benchmark.
svcadm disable webconsole (Unix, superuser commands)
Turns off the Sun Web Console, a browser-based interface that performs systems management.
If it is enabled, system administrators can manage systems, devices and services from remote systems.
ts_dispatch_extended=<n> (Unix /etc/system)
Controls which dispatch table is loaded upon boot. A value of 1 loads the large system table, a value of 0 loads the regular system table.
tune_t_fsflushr=<n> (Unix /etc/system)
Controls the number of seconds between runs of the file system flush daemon, fsflush.
ulimit -s <n> (Unix shell)
Sets the stack size to n kbytes, or "unlimited" to allow the stack size to grow without limit.
Note that the "heap" and the "stack" share space; if your application allocates large amounts of memory on the heap,
then you may find that the stack limit should not be set to "unlimited". A commonly used setting for SPEC CPU2006 purposes
is a stack size of 128MB (131072K).
For questions about the meanings of these flags, please contact the tester.
For other inquiries, please contact webmaster@spec.org
Copyright 2006-2014 Standard Performance Evaluation Corporation
Tested with SPEC CPU2006 v1.0.1.
Report generated on Tue Jul 22 16:07:10 2014 by SPEC CPU2006 flags formatter v6906.
![[benchmark]](http://www.spec.org/auto/cpu2006/flags/benchmark.png)
![[suite]](http://www.spec.org/auto/cpu2006/flags/suite.png)