Application performance is an important goal of the Intel® Compilers, even at default optimization levels. A number of optimizations involve transformations that might affect the floating-point behavior of the application, such as evaluation of constant expressions at compile time, hoisting invariant expressions out of loops, or changes in the order of evaluation of expressions. These optimizations usually help the compiler to produce the most efficient code possible. However, the optimizations might be contrary to the floating-point requirements of the application.
Some optimizations are not consistent with strict interpretation of the ANSI or ISO standards for C and C++. Such optimizations can cause differences in rounding and small variations in floating-point results that may be more or less accurate than the ANSI-conformant result.
Intel Compilers provide the -fp-model (Linux* and Mac OS* X) or /fp (Windows*) option, which allows you to control the optimizations performed when you build an application. The option allows you to specify the compiler rules for:
Value safety: Whether the compiler may perform transformations that could affect the result. For example, in the SAFE mode, the compiler won't transform x/x to 1.0 because the value of x at runtime might be a zero or a NaN . The UNSAFE mode is the default.
Floating-point expression evaluation: How the compiler should handle the rounding of intermediate expressions. For example, when double precision is specified, the compiler interprets the statement t0=4.0f+0.1f+t1+t2; as t0=(float)(4.1+(double)t1+(double)t2);
Floating-point contractions: Whether the compiler should generate fused multiply-add (FMA) instructions on processors that support them. When enabled, the compiler may generate FMA instructions for combining multiply and add operations; when disabled, the compiler must generate separate multiply and add instructions with intermediate rounding.
Floating-point environment access: Whether the compiler must account for the possibility that the program might access the floating-point environment, either by changing the default floating-point control settings or by reading the floating-point status flags. This is disabled by default. You can use the -fp-model:strict (Linux and Mac OS X) /fp:strict (Windows) option to enable it.
Precise floating-point exceptions: Whether the compiler should account for the possibility that floating-point operations might produce an exception. This is disabled by default. You can use -fp-model:strict (Linux and Mac OS X) or /fp:strict (Windows); or -fp-model:except (Linux and Mac OS X) or /fp:except (Windows) to enable it.
Consider the following example:
double a=1.5;
int x=0;
...
__try {
int t0=a; //raises inexact
x=1;
a*=2;
} __except(1) {
printf("SEH Exception: x=%d\n", x);
}
Without precise floating-point exceptions, the result is SEH Exception: x=1; with precision floating-point exceptions, the result is SEH Exception: x=0.
The following table describes the impact of different keywords of the option on compiler rules and optimizations:
Keyword |
Value Safety |
Floating-Point |
Floating-Point |
Floating-Point |
Precise Floating-Point |
|---|---|---|---|---|---|
precise |
Varies |
Source |
Yes |
No |
No |
strict |
Varies |
Source |
No |
Yes |
Yes |
fast=1 (default) |
Unsafe |
Unknown |
Yes |
No |
No |
fast=2 |
Unsafe |
Unknown |
Yes |
No |
No |
except |
Unaffected |
Source |
Unaffected |
Unaffected |
Yes |
Note
It is illegal to specify the except keyword in an unsafe safety mode.
Based on the objectives of an application, you can choose to use different sets of compiler options and keywords to enable or disable certain optimizations, so that you can get the desired result.