[llvm-dev] [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?
John Reagan via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 12 08:41:45 PST 2018
I'll give some data points from our OpenVMS Itanium (and Alpha)
platforms where we support multiple IEEE modes and dynamic rounding in
our C and Fortran compilers (we don't have actual FENV_ACCESS in our C
product but you can come close).
On the command line, you get to pick IEEE modes with:
Selects the IEEE floating-point mode to be used.
FAST During program execution, only finite values (no
infinities, NaNs, or denorms) are created.
Exceptional conditions, such as floating point
overflow and divide by zero, are fatal.
UNDERFLOW_TO_ZERO Generate infinities and NaNs. Flush
denormalized results and underflow to zero
DENORM_RESULTS Same as UNDERFLOW_TO_ZERO, except that denorms
are generated. This is the default for I64
INEXACT Same as DENORM_RESULTS, except that inexact
values are trapped. This is the slowest mode.
and rounding modes
For /FLOAT=IEEE_MODE, the /ROUNDING_MODE qualifier lets you select
one of the following IEEE rounding modes:
o NEAREST (default)
And "strict" modes
Controls compiler assumptions. You may select the following
Specifies whether certain code transformations that affect
floating-point operations are allowed. These changes may or
may not affect the accuracy of the program's results.
If you specify NOACCURACY_SENSITIVE, the compiler is free to
reorder floating-point operations, based on algebraic
identities (inverses, associativity, and distribution). This
allows the compiler to move divide operations outside of
loops, improving performance.
The default, ACCURACY_SENSITIVE, directs the compiler to use
only certain scalar rules for calculations. This setting can
prevent some optimization.
if you pick DYNAMIC, you can then use a system call
(SYS$IEEE_SET_ROUNDING_MODE) to change the value. We warn in our
manuals that /ROUNDING=DYNAMIC may have a significant performance
impact. The idea is that you set the mode [the routine returns the
prior mode], do you work, put the old mode back. You would collect such
code into its own module and compile with with DYNAMIC but compile the
majority of your code with the defaults.
We've had our default be "strict" with /ASSUME=ACCURACY_SENSITIVE for
years and let people specify NOACCURACY if desired. We don't tie it to
any optimization level. It is a separate knob.
More information about the llvm-dev