This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Two places in GCC doing (float)func(x) -> funcf(x) ??


On Sat, 13 Mar 2004, Kaveh R. Ghazi wrote:
> I see two places that ostensibly claim to transform for example:
> 	(float)trunc((float)foo) -> truncf(foo)
>
> one place is in convert_to_real() and one place is in
> fold_trunc_transparent_mathfn().
>
> 1.  Why two places?  Are they equivalent or did I misread it?

I had to re-read the code several times myself to convince myself
they are slightly different transformations.  As you point out,
the commentary in convert_to_real could certainly be improved.

convert_to_real transforms (float)trunc(d) into truncf((float)d).
fold_trunc_transparent_mathfn transforms trunc((double)f) into
(double)truncf(f).

In both, the "width" of the operation is always reduced by the
transformation;  long double -> double -> float.  The first pushes
the cast into the argument to strength reduce the builtin, and the
second pulls the cast out.  In the first, the outer most tree node
is a cast (NOP_EXPR), but in the second, the outer node is the builtin.


> 2.  convert_to_real claims to be disabled in comments, but it's not?

Agreed.  This is a documentation bug.  The middle-end builtins now
know when the C99 float versions of functions, such as sqrtf, are
available, and mathfn_builtin_in returns NULL when not available.


> 3.  convert_to_real has some typos for the supposedly long double
>     BUILT_IN_ROUND, BUILT_IN_TRUNC and BUILT_IN_NEARBYINT.

Agreed.  This is also a bug.  Fortunately, these typos just miss
optimization opportunities, and can't cause incorrect code.


> 4.  Can't we handle BUILT_IN_RINT the same way we do the others?

I believe that rint can be handled the same way as the others, provided
that rounding modes of float, double and long double are not independent.
i.e. rintf, rint and rintl must always have the same run-time rounding
mode.  I'm not sure what the standards have to say, nor whether any of the
FPUs out there support per-mode rounding.

[My belief of the safety of these transformations relies on the theorem
that for any non-integer value that can be represented by a floating
point format, the "floor" and "ceil" integers of that value can always
be represented in that format.  A corrolary is that integer rounding
functions always return a finite result for a finite input.]


Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]