Re: The conditions when convert from double to float is permitted?

[Xionghu Luo via Gcc]

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? 
(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.)

Currently, gimple code already generates below code(though no ABSF_EXPR or 
EXPF_EXPR),
but due to ABS_EXPR return double, many double conversions are also produced
for the MUL and ADD operations, and that why I propose to do it in match.pd.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326#c9, also refused by you due 
to
complex static pattern matching, also it will cause potential Inf issue like 
last mail.)

1) cat liv.c.006t.gimple
__attribute__((noinline))
foo (float x, float y, float z)
{
  float D.4356;

  _1 = ABS_EXPR <x>;
  _2 = (double) _1;
  _3 = (double) y;
  _4 = _2 * _3;
  _5 = (double) z;
  _6 = _4 + _5;
  D.4356 = (float) _6;
  return D.4356;
}

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

2) cat liv.c.006t.gimple
__attribute__((noinline))
foo (double x, float y, float z)
{
  float D.4356;

  _1 = ABS_EXPR <x>;
  _2 = (double) y;
  _3 = _1 * _2;
  _4 = (double) z;
  _5 = _3 + _4;
  D.4356 = (float) _5;
  return D.4356;
}

> 
> So I'm not entirely convinced such transform is a good idea, at least
> by default with -ffast-math.  Maybe have a -fassume-float-limited-range
> or so documented as that we assume that double or long double values
> used fit in floats?

Thanks for the idea, just to confirm where should this option work,  In match.pd
or gimple pass for only abs/exp to absf/expf, etc?  Even with the option, I am
afraid the option is still not effective for computation? :)


Thanks,
Xionghu