question about -ffast-math implementation

[Tim Prince]

On 6/2/2014 3:00 AM, Andrew Pinski wrote:
> On Sun, Jun 1, 2014 at 11:09 PM, Janne Blomqvist
> <blomqvist.janne@gmail.com> wrote:
>> On Sun, Jun 1, 2014 at 9:52 AM, Mike Izbicki <mike.izbicki@gmail.com> wrote:
>>> I'm trying to copy gcc's behavior with the -ffast-math compiler flag
>>> into haskell's ghc compiler.  The only documentation I can find about
>>> it is at:
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
>>>
>>> I understand how floating point operations work and have come up with
>>> a reasonable list of optimizations to perform.  But I doubt it is
>>> exhaustive.
>>>
>>> My question is: where can I find all the gory details about what gcc
>>> will do with this flag?  I'm perfectly willing to look at source code
>>> if that's what it takes.
>>
>> In addition to the official documentation, a nice overview is at
>>
>> https://gcc.gnu.org/wiki/FloatingPointMath
Useful, thanks for the pointer
>>
>> Though for the gory details and authoritative answers I suppose you'd
>> have to look into the source code.
>>
>>> Also, are there any optimizations that you wish -ffast-math could
>>> perform, but for various architectural reasons they don't fit into
>>> gcc?
>>
>> There are of course a (nearly endless?) list of optimizations that
>> could be done but aren't (lack of manpower, impractical, whatnot). I'm
>> not sure there are any interesting optimizations that would be
>> dependent on loosening -ffast-math further?
I find it difficult to remember how to reconcile differing treatments by 
gcc and gfortran under -ffast-math; in particular, with respect to 
-fprotect-parens and -freciprocal-math.  The latter appears to comply 
with Fortran standard.
>>
>> (One thing I wish wouldn't be included in -ffast-math is
>> -fcx-limited-range; the naive complex division algorithm can easily
>> lead to comically poor results.)
>
> Which is kinda interesting because the Google folks have been trying
> to turn on  -fcx-limited-range for C++ a few times now.
>
Intel tried to add -complex-limited-range as a default under -fp-model 
fast=1 but that was shown to be unsatisfactory.

Now, with the introduction of omp simd directives and pragmas, we have 
disagreement among various compilers on the relative roles of the 
directives and the fast-math options.
I've submitted PR60117 hoping to get some insight on whether omp simd 
should disable optimizations otherwise performed by -ffast-math.

Intel made the directives over-ride the compiler line fast (or 
"no-fast") settings locally, so that complex-limited-range might be in 
effect inside the scope of the directive (no matter whether you want 
it).  They made changes in the current beta compiler, so it's no longer 
practical to set standard-compliant options but discard them by pragma 
in individual for loops.


-- 
Tim Prince