Re: Unreviewed patches

[Roger Sayle <roger at eyesopen dot com>]

Zack Weinberg <zack@codesourcery.com> writes:
> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> > My math builtins patches have been in the queue for over a week.
>
> These three ... are approved.  The others I am not thinking clearly
> enough to review, sorry.

If its any help, they all look technically sound to me.
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00309.html
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00398.html
http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00449.html


> I am a little suspicious of mathfn_built_in's apparent propensity to
> change the function the user called.  If I write
>
>  double x, y;
>  x = some_number;
>  y = sqrtf(x);

> I might in fact have _wanted_ the truncation to float.  Now, your
> patch does not change that behavior, so it is fine, but I want to
> raise the concern anyway.

Fear not, the logic for this optimization, on line 158 of convert.c,
only changes the math library function call to a lower precision,
when the extra precision would be cast away anyway.  GCC will leave
your example above unchanged.

Given (outermode)op((opmode)x), where x has mode innermode, we change
the mode of the operation to min(opmode, max(innermode, outermode)).
In the example above this is min(float, max(double, double)) which is
float, i.e. sqrtf will still be called.

For its intended target:

   float x, y;
   y = sqrt(x)

we perform the operation in min(double, max(float, float)) which is
float, so we'll call sqrtf.

And for another example:

  float x;
  double y;
  y = sqrt(x);

we perform the operation in min(double, max(float,double)) which is
double, so again we preserve the user's original call.

Basically, if a user calls a math function that will obviously
truncate the result, Jan's optimization should leave it unchanged.


Roger
--