The conditions when convert from double to float is permitted?

[Segher Boessenkool]

On Fri, Dec 11, 2020 at 05:38:30PM +0800, Xionghu Luo wrote:
> On 2020/12/11 15:47, Richard Biener wrote:
> >> 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.
> > Yes.  As said it's difficult to second guess the programmer here.
> > The existing cases doing promotion look at unary functions,
> > doing exp->expf when arguments are promoted floats and the
> > return value is casted back to float.  That's also a common programmer
> > "error" not knowing expf or assuming some kind of magic overloading.
> 
> Yes, that is "(float) fabs (float)" -> "(float) fabsf (float)" as (1), 
> that seems should be done in front end to generate fabsf or "warning" to programmer? 

Doing it in the frontend means we'll have to do it in every frontend
separately.  This optimisation is valid in any language.

> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c4, refused by Andew and Joseph,
> reason is front end shouldn't do any optimization there.)

Yeah.  It currently *does* in many cases, but that is bad architecture.

> For "(float) fabs (double)" like (2), it is not quite reasonable to do fabs -> fabsf.

It brings no benefit to have fabsf over fabs insns, either.


Segher