On Fri, Dec 11, 2020 at 03:54:44PM +0800, Xionghu Luo wrote:
> +cc.
>
>
> On 2020/12/11 14:25, Xionghu Luo via Gcc wrote:
> >Thanks,
> >
> >On 2020/12/10 17:12, Richard Biener wrote:
> >>>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).
Since both "red"s here are unsigned 16-bit integers, the result fits in
an unsigned 19-bit integer, so both SP float and integer calculations
woould work just fine here.
> >>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).
> >>
> >
> > foo (double x, float y, float z)
> > {
> > return ( fabs (x) * y - z ) ;
> > }
Since x is double, you have to do this all in double precision, even with
-ffast-math! The subtraction could do catastrophic cancellation.
> >But the add/sub could also produces INF similarly,
> >
> > foo (double x, float y, float z)
> > {
> > return ( -fabs (x) + y + z ) ;
> > }
Here you can lose on the order of just a single bit, so it is okay to do
all this in single precision with -ffast-math.
> >Note that the add/sub sequence is different for (3) and (4) since
> >-funsafe-math-optimizations is implicitly true. "fp-contract=fast" in
> >(1) and (2) could avoid Inf as fmads could handle float overflow (verified
> >it on Power, not sure other targets support this), but without float
> >value-range info, it is unsafe to change computation from double to
> >float even for only add/sub expressions.
Yeah exactly.
Segher
