[2/3] powerpc: POWER8 fmod optimization

  This patch adds a POWER8 fmod optimization.  The implementation uses
floating point operations instead of default one which uses integers.
Inputs are handled for finite mode (since the symbol is meant to be used
with -ffinite-math-only) and inexact exceptions are disabled in FP
calculation.

Using GLIBC fmod benchmark:

* Default fmod:

  "fmod": {
   "": {
    "duration": 5.1043e+09,
    "iterations": 2.67654e+08,
    "max": 106.892,
    "min": 5.939,
    "mean": 19.0705
   }

* Patched version:

  "fmod": {
   "": {
    "duration": 5.08466e+09,
    "iterations": 6.35088e+08,
    "max": 92.284,
    "min": 6.849,
    "mean": 8.00623
   }

Tested on powerpc64 and powerpc64le.

--

	* sysdeps/powerpc/powerpc64/power8/fpu/e_fmod.S: New file: POWER8 fmod
	optimization.
	* sysdeps/powerpc/powerpc64/power8/fpu/e_fmodf.S: New file: POWER8
	fmodf optimization.

---
  

On Tue, 11 Nov 2014, Adhemerval Zanella wrote:

> +	mtfsb0  4*cr7+lt	/* Disable FE_INEXACT exception  */

Disable trapping?  If you disable trapping, you need to restore the 
previous state of that bit before returning.

> +	fdiv    fp0,fp1,fp2	/* fp0 = -trunc (fp1 / fp2)  */
> +	fneg    fp0,fp0
> +	friz    fp0,fp0
> +	fmadd   fp2,fp0,fp2,fp1 /* fp2 = x - (fp0) * y  */

Are you sure this is correct when the integer quotient is not exactly 
representable in IEEE double?  I'd expect you to need a loop in the case 
of large exponent differences.

> +	fcpsgn  fp1,fp1,fp2
> +	mtfsb0  4*cr1+eq	/* Clear any FE_INEXACT exception  */

Clear any FE_INEXACT bit, whether or not set before the function?  It's 
not correct for <math.h> functions to clear exception bits that were 
already set - only bits they set, if previously clear.  (See bug 15491 for 
such a bug in x86 nearbyint.)
  

On 11-11-2014 19:28, Joseph Myers wrote:
> On Tue, 11 Nov 2014, Adhemerval Zanella wrote:
>
>> +	mtfsb0  4*cr7+lt	/* Disable FE_INEXACT exception  */
> Disable trapping?  If you disable trapping, you need to restore the 
> previous state of that bit before returning.
>
>> +	fdiv    fp0,fp1,fp2	/* fp0 = -trunc (fp1 / fp2)  */
>> +	fneg    fp0,fp0
>> +	friz    fp0,fp0
>> +	fmadd   fp2,fp0,fp2,fp1 /* fp2 = x - (fp0) * y  */
> Are you sure this is correct when the integer quotient is not exactly 
> representable in IEEE double?  I'd expect you to need a loop in the case 
> of large exponent differences.

Indeed I overlook it, as I am seeing now with a more extensive testing.  Checking now,
it seems using a FP division operation in the loop to correct it not the best
strategy to achieve better performance.

>> +	fcpsgn  fp1,fp1,fp2
>> +	mtfsb0  4*cr1+eq	/* Clear any FE_INEXACT exception  */
> Clear any FE_INEXACT bit, whether or not set before the function?  It's 
> not correct for <math.h> functions to clear exception bits that were 
> already set - only bits they set, if previously clear.  (See bug 15491 for 
> such a bug in x86 nearbyint.)
>
  

On Wed, 12 Nov 2014, Adhemerval Zanella wrote:

> Indeed I overlook it, as I am seeing now with a more extensive testing.  
> Checking now, it seems using a FP division operation in the loop to 
> correct it not the best strategy to achieve better performance.

And there are other problems with the division I didn't notice previously.  
If the exponent difference is large enough, the division may overflow.  
And you're assuming the result of (round to next integer toward 0 (divide 
and round in current rounding mode)) is the same as (divide in infinite 
precision, round once to an integer toward 0) - but depending on the 
arguments and rounding mode, the result of the division may be rounded 
away from 0 to an integer with magnitude greater than the desired result.
  

On 12-11-2014 14:19, Joseph Myers wrote:
> On Wed, 12 Nov 2014, Adhemerval Zanella wrote:
>
>> Indeed I overlook it, as I am seeing now with a more extensive testing.  
>> Checking now, it seems using a FP division operation in the loop to 
>> correct it not the best strategy to achieve better performance.
> And there are other problems with the division I didn't notice previously.  
> If the exponent difference is large enough, the division may overflow.  
> And you're assuming the result of (round to next integer toward 0 (divide 
> and round in current rounding mode)) is the same as (divide in infinite 
> precision, round once to an integer toward 0) - but depending on the 
> arguments and rounding mode, the result of the division may be rounded 
> away from 0 to an integer with magnitude greater than the desired result.
>
Yes, I noted that my naive approach is far from correct.  I'm dropping this patch,
thanks for the review.