RFC: https://discourse.llvm.org/t/rfc-the-meaning-of-ofast/66554
-Ofast is defined as -O3 -ffast-math
-ffast-math will mean the following:
- -fno-honor-infinities
- -fno-honor-nans
- -fassociative-math
- -freciprocal-math
- -fapprox-func
- -fno-signed-zeros
- -ffp-contract=fast
This definition matches the meaning of the "fast" attribute in LLVM IR: https://llvm.org/docs/LangRef.html#fast-math-flags
-fstack-arrays should also be enabled with -Ofast but that flang is not yet implemented and so has been left for a future patch.
clang -cc1 accepts -Ofast. I did not add -Ofast to flang-new -fc1 because it is redundant because the compiler driver will always resolve -Ofast into -O3 -ffast-math (I added a test for this in flang/test/Driver/fast_math.f90; there is a test that -ffast-math leads to the fast attribute in flang/test/Lower/fast-math-arithmetic.f90). This means that flang-new -Ofast will be forwarded as flang-new -fc1 -O3 -ffast-math, which is entirely equivalent. Avoiding adding the umbrella flag to flang-new -fc1 avoids unnecessary complexity in the frontend driver.
-menable-infs is removed from the frontend-forwarding test because if all of the fast-math component flags are present, these will be resolved into the fast-math flag. Instead -menable-infs is tested in the fast-math test.
-fno-fast-math will not make FPContract less strict: -ffp-contract=off -fno-fast-math will not reset to -ffp-contract=fast (the default).
So this means that:
I would reduce this comment to that ^^^. In particular, what if this is no longer true: "// FPContract = fast is the default anyway" ?
Also, could you mention this in the summary? This a design decision worth documenting.