/fp:source vs /fp:fast (or fast2)

/fp:source vs /fp:fast (or fast2)

I've compiled our large project with both switches. The some 400 test files are mostly nearly equal in both cases with a few having large diffs. In one particular case, I'm interested in tracking down what the possible differences could be (as it is only for a few variables), but I'm a bit stumped at what to look for.

So, any hints on what to look for in code would be helpful.

Also -- if I were to run both versions in debug -- /fp:fast and /fp:source -- would that show up those kinds of diffs?

Any hints appreciated.

Linda

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

If you were considering whether to use /fp:source vs. /fp:fast, you would probably add additional flags to narrow the differences, such as -Qftz -assume:protect_parens -Qprec-div -Qprec-sqrt. You should look up those individual options; /fp:source by itself turns off ftz and should set those other options.
If you allow your debug option to set /Od, it will eliminate most of the aggressive effects of /fp:fast. If you set the same /O level as your release mode, debug will not change the effect of these options.
The most visible effect of /fp:fast=2 is to set complex limited range, where the valid exponent range for complex is cut by half. This would permit vectorization of many complex operations, but isn't worth considering if you don't have vectorizable complex.
The most visible effect of /fp:fast -assume:protect_parens -Qprec-div -Qprec-sqrt is to permit vectorization of sum reductions which aren't permitted under /fp:source. Vectorization of reductions usually gives a slightly improved accuracy which may vary with data alignment.

Okay -- should have said I already have the options you mention on in both: assume:protect_parens -Qprec-div -Qprec-sqrt

I also, at the same time had switched from fp:speculation=off to speculation=fast.

We have no complex numbers being used in the code.

Linda

We're getting close to thinking this may be a compiler bug. (Similar to ones we saw with 11.0 but obviously not the same.

I may go back and load update 5 and see if it occurred there.

Linda

Leave a Comment

Please sign in to add a comment. Not a member? Join today