On Thu, Dec 10, 2020 at 9:47 AM Xionghu Luo via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
> I have a maybe silly question about whether there is any *standard*
> or *options* (like -ffast-math) for GCC that allow double to float
> demotion optimization? For example,
The only option we have to this effect would be -funsafe-math-optimizations.
But even with that we usually try to bound errors - not miscomparing
SPEC CPU with -Ofast (which includes -funsafe-math-optimizations)
is one of the goals.
For the specific case...
> 1) from PR22326:
>
> #include <math.h>
>
> float foo(float f, float x, float y) {
> return (fabs(f)*x+y);
> }
>
> The fabs will return double result but it could be demoted to float
> actually since the function returns float finally.
>
> 2) From PR90070:
>
> double temp1 = (double)r->red;
> double temp2 = (double)aggregate.red;
> double temp3 = temp2 + (temp1 * 5.0);
temp1 * 5 could be not representable in float but the
result of the add could so the transform could result
in -+Inf where the original computation was fine (but
still very large result).
Usually in such cases one could say we should implement some
diagnostic hints to the user that he might consider refactoring
his code to use float computations because we cannot really say
whether it's safe (we do at the moment not implement value-range
propagation for floating point types).
> aggregate.red = (float) temp3;
>
> The last data type is also float, so we could also replace the double
> precision calculation with single precision.
>
> So, Is it OK to use float instead of double for all or we could ONLY
> replace cases when there is explicit double to float conversion in
> source code for fast-math build?
>
> However, fast-math option doesn't directly means we could ignore the
> precision.
>
> @item -ffast-math
> @opindex ffast-math
> Sets the options @option{-fno-math-errno},
> @option{-funsafe-math-optimizations},
> @option{-ffinite-math-only}, @option{-fno-rounding-math},
> @option{-fno-signaling-nans}, @option{-fcx-limited-range} and
> @option{-fexcess-precision=fast}.
>
>
> Background is I cooked a patch to track all the double<->float related
> convert instructions in backprop pass backwardly, and optimize these
> instructions (including assignment in basic block and phi instructions
> cross basic block) from double to float with type check, though most
> regression test cases passed, there are a few gfortran cases reported
> run error of IEEE_INVALID_FLAG, I didn't root caused where the error
> happens yet.
> There are doubts whether this kind of optimization is *legal* for fast math?
> If there are many converts happens in different blocks/regions, how to split
> them to avoid interference?
With fast math any optimization is *legal* (all applicable rules are lifted) but
we still want to adhere to some basic QOI, otherwise fast math becomes
useless.
> Attached the patch. Sorry that the code has many hacks and not well refined
> as
> it is still at very early version and just functionally works for most cases.
>
>
> Thanks,
> Xionghu
