There are currently two options that are used to tell the compiler to perform unsafe floating-point optimizations: '-ffast-math' and '-funsafe-math-optimizations'.
'ffast-math' is enabled by default. It automatically enables the driver option '-menable-unsafe-fp-math'.
Below is a table illustrating the special operations enabled automatically by '-ffast-math', '-funsafe-math-optimizations' and '-menable-unsafe-fp-math' respectively.
Special Operations | -ffast-math | -funsafe-math-optimizations | -menable-unsafe-fp-math |
MathErrno | 0 | 1 | 1 |
FiniteMathOnly | 1 | 0 | 0 |
AllowFPReassoc | 1 | 1 | 1 |
NoSignedZero | 1 | 1 | 1 |
AllowRecip | 1 | 1 | 1 |
ApproxFunc | 1 | 1 | 1 |
RoundingMath | 0 | 0 | 0 |
UnsafeFPMath | 1 | 0 | 1 |
FPContract | fast | on | on |
'-ffast-math' enables '-fno-math-errno', '-ffinite-math-only', '-funsafe-math-optimzations' and sets 'FpContract' to 'fast'. The driver option
'-menable-unsafe-fp-math' enables the same special options than '-funsafe-math-optimizations'. This is redundant. We propose to remove the driver
option '-menable-unsafe-fp-math' and use instead, the setting of the special operations to set the function attribute 'unsafe-fp-math'. This attribute will
be enabled only if those special operations are enabled and if 'FPContract' is either 'fast' or set to the default value.
If I look at the clang driver code, -funsafe-math-optimizations is specified on the CC1 command line if
is true.
This means that it shouldn't matter the value of the floating point contraction, or whether infs/nans are honored or not.
Was there another issue that this specific part of the change addresses?