Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License,
Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being "Funding Free
Software", the Front-Cover Texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the
license is included in your SPEC CPU kit at $SPEC/Docs/licenses/FDL.v1.3.txt and on the web at http://www.spec.org/cpu2017/Docs/licenses/FDL.v1.3.txt.
A copy of "Funding Free Software" is on your SPEC CPU kit at $SPEC/Docs/licenses/fsf-funding.txt and on the web at http://www.spec.org/cpu2017/Docs/licenses/fsf-funding.txt.

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free
Software Foundation raise funds for GNU development.

Sections

Selecting one of the following will take you directly to that section:

Tells GCC to use the GNU semantics for "inline" functions, that is, the behavior prior to the C99 standard.
This switch may resolve duplicate symbol errors, as noted in the 502.gcc_r benchmark description.

The language standards set aliasing requirements: programmers are expected to follow conventions so that the
compiler can keep track of memory. If a program violates the requirements (for example, using pointer arithmetic),
programs may crash, or (worse) wrong answers may be silently produced.

Unfortunately, the aliasing requirements from the standards are not always well understood.

Sometimes, the aliasing requirements are understood and nevertheless intentionally violated by smart programmers who
know what they are doing, such as the programmer responsible for the inner workings of Perl storage allocation and
variable handling.

There are a group of GCC optimizations invoked via -ftree-vectorize and related flags, as
described at
https://gcc.gnu.org/projects/tree-ssa/vectorization.html. During testing of SPEC CPU2017, for some versions of
GCC on some chips, some benchmarks did not get correct answers when the vectorizor was enabled. These problems were
to isolate, and it is possible that later versions of the compiler might not encounter them.

The switch -funsafe-math-optimizations allows the compiler to make certain(*) aggressive assumptions, such as
disregarding the programmer's intended order of operations. The run rules allow such re-ordering
http://www.spec.org/cpu2017/Docs/runrules.html#reordering. The rules also point out that you must get answers
that pass SPEC's validation requirements. In some cases, that will mean that some optimizations must be turned off.

Applies information from a profile run in order to improve optimization.
Several optimizations are improved when profile data is available, including branch probabilities, loop peeling, and loop
unrolling.

-mrecip
This option enables use of "RCPSS" and "RSQRTSS" instructions (and
their vectorized variants "RCPPS" and "RSQRTPS") with an additional
Newton-Raphson step to increase precision instead of "DIVSS" and
"SQRTSS" (and their vectorized variants) for single-precision
floating-point arguments. These instructions are generated only when
-funsafe-math-optimizations is enabled together with
-finite-math-only and -fno-trapping-math.
-mrecip=opt
This option controls which reciprocal estimate instructions may be
used. opt is a comma-separated list of options, which may be
preceded by a ! to invert the option:
all
Enable all estimate instructions.
default
Enable the default instructions, equivalent to -mrecip.
none
Disable all estimate instructions, equivalent to -mno-recip.
div Enable the approximation for scalar division.
vec-div
Enable the approximation for vectorized division.
sqrt
Enable the approximation for scalar square root.
vec-sqrt
Enable the approximation for vectorized square root.
So, for example, -mrecip=all,!sqrt enables all of the reciprocal
approximations, except for square root.

Increases optimization levels: the higher the number, the more optimization is done. Higher levels of optimization may
require additional compilation time, in the hopes of reducing execution time. At -O, basic optimizations are performed,
such as constant merging and elimination of dead code. At -O2, additional optimizations are added, such as common
subexpression elimination and strict aliasing. At -O3, even more optimizations are performed, such as function inlining and
vectorization.
Many more details are available.

numactl runs processes with a specific NUMA scheduling or memory placement policy. The policy is set for a
command and inherited by all of its children.

--localalloc instructs numactl to keep a process memory on the local node while -m specifies which node(s) to
place a process memory.

--physcpubind specifies which core(s) to bind the process. In this case, copy 0 is bound to processor 0
etc.

For full details on using numactl, please refer to your Linux documentation, man numactl

Solaris systems: The pbind command is commonly used, via
submit=echo 'pbind -b...' > dobmk; sh dobmk
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 run 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, the jobs are typically
distributed evenly across the system, with each chip running the same number of jobs as all other chips, and each
core running the same number of jobs as all other cores.

The pbind expression may include various elements from the SPEC toolset and from standard Unix commands, such
as:

One or more of the following may have been used in the run. If so, it will be listed in the notes sections. Here
is a brief guide to understanding them:

LD_LIBRARY_PATH=<directories> (set via config file preENV)
LD_LIBRARY_PATH controls the search order for libraries. Often, it can be defaulted. Sometimes, it is
explicitly set (as documented in the notes in the submission), in order to ensure that the correct versions of
libraries are picked up.