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
