4 ms·

Imo the best solution would be special "fast" floating-point types, that have less strict requirements. I personal almost always use -ffast-math by default in

Imo the best solution would be special "fast" floating-point types, that have less strict requirements. I personal almost always use -ffast-math by default in my C programs that care about performance, because I almost never care enough about the loss in accuracy. The only case I remember needing it was when doing some random number distribution tests where I cared about subnormals, and got confused for a second because they didn't seem to exist (-ffast-math disables them on x86).

lifthrasiir 3y ago
That or a scoped optimization directive. GCC does allow `__attribute__((optimize("-ffast-math")))` as a function-wide attribute, but Clang doesn't seem to have an equivalent and the standard syntax `[[gcc::optimize("-ffast-math")]]` doesn't seem to work as well. In any case, such optimization should be visible from the code in my opinion.
- lorenzored 3y ago
  The problem is that it takes a single piece of code compiled with -ffast-math to break everything, it's simply not worth it
  - masklinn 3y ago
    GP seems to be saying that you can flag individual functions in GCC, thereby avoiding this issue: only flagged functions would be compiled with fast math semantics.
    - lorenzored 3y ago
      This only work if it's a leaf function that will throw away the result. If you feed the result of your --fast-math function into other working code you risk breaking it.
      - lifthrasiir 3y ago
        `-ffast-math` is fully local, asides from GCC's unexpected `crtfastmath.o` linkage which is global. Functions with `-ffast-math` enabled still return fp values via usual registers and in usual formats. If some function `f` is expected to return -1.0 to 1.0 for particluar inputs, `-ffast-math` can only make it to return 1.001 or NaN instead. If another function without `-ffast-math` expects and doesn't verify f's return value, it will surely misbehave, but only because the original analysis of f no longer holds. `-ffast-math` the compiler option is bad because this effect is not evident from the code. Anything visible in the code should be okay.

lifthrasiir 3y ago

That or a scoped optimization directive. GCC does allow `__attribute__((optimize("-ffast-math")))` as a function-wide attribute, but Clang doesn't seem to have an equivalent and the standard syntax `[[gcc::optimize("-ffast-math")]]` doesn't seem to work as well. In any case, such optimization should be visible from the code in my opinion.

lorenzored 3y ago
The problem is that it takes a single piece of code compiled with -ffast-math to break everything, it's simply not worth it
- masklinn 3y ago
  GP seems to be saying that you can flag individual functions in GCC, thereby avoiding this issue: only flagged functions would be compiled with fast math semantics.
  - lorenzored 3y ago
    This only work if it's a leaf function that will throw away the result. If you feed the result of your --fast-math function into other working code you risk breaking it.
    - lifthrasiir 3y ago
      `-ffast-math` is fully local, asides from GCC's unexpected `crtfastmath.o` linkage which is global. Functions with `-ffast-math` enabled still return fp values via usual registers and in usual formats. If some function `f` is expected to return -1.0 to 1.0 for particluar inputs, `-ffast-math` can only make it to return 1.001 or NaN instead. If another function without `-ffast-math` expects and doesn't verify f's return value, it will surely misbehave, but only because the original analysis of f no longer holds. `-ffast-math` the compiler option is bad because this effect is not evident from the code. Anything visible in the code should be okay.