[1/3] Optimize trunc() and truncf().

  By creating a mask of non-fractional bits from the exponent.
---

Joseph suggested an SSE 4.1 implementation of trunc/truncf, so I thought
now would be a good time to send these patches even sans benchmarking data.

I do not believe the other two generic trunc* implementations (ldbl-128,
dbl-64) would benefit from the change made in this patch

Suggestions for ChangeLog entries welcome. Guidance for generating benchmark
data requested.

 sysdeps/ieee754/dbl-64/wordsize-64/s_trunc.c | 32 +++++++++++-----------------
 sysdeps/ieee754/flt-32/s_truncf.c            | 32 +++++++++++-----------------
 2 files changed, 26 insertions(+), 38 deletions(-)
  

On 05/25/2016 03:32 AM, Matt Turner wrote:
 > +  int64_t exp = (i0 >> 52) & 0x7ff;
 > +  int64_t mask = UINT64_C(-1) << max(52 - (exp - 1023), 0);

I think it will help GCC if you make exp an int and change the max 
function accordingly.

You should use spaces in front of the parenthesis in a function call, 
and also for most macro calls.

Thanks,
Florian
  

On Tue, 24 May 2016, Matt Turner wrote:

> +  int64_t exp = (i0 >> 52) & 0x7ff;
> +  int64_t mask = UINT64_C(-1) << max(52 - (exp - 1023), 0);

This can involve undefined behavior (shift by more than 63), so ...

> +  if (exp < 1023)
> +    mask = UINT64_C(0x8000000000000000);

... the shift should only be done at all if exp is large enough.

Likewise for truncf.
  

On Tue, 24 May 2016, Matt Turner wrote:

> -  else
> -    {
> -      if (j0 == 0x400)
> -	/* x is inf or NaN.  */
> -	return x + x;
> -    }

You're removing too much code here.  You need to keep this addition in the 
NaN case to ensure that signaling NaNs raise "invalid" and get converted 
to quiet NaNs in the process.
  

On 25 May 2016 15:36, Joseph Myers wrote:
> On Tue, 24 May 2016, Matt Turner wrote:
> > -  else
> > -    {
> > -      if (j0 == 0x400)
> > -	/* x is inf or NaN.  */
> > -	return x + x;
> > -    }
> 
> You're removing too much code here.  You need to keep this addition in the 
> NaN case to ensure that signaling NaNs raise "invalid" and get converted 
> to quiet NaNs in the process.

does this mean current test coverage is insufficient ?
-mike
  

On Wed, 25 May 2016, Mike Frysinger wrote:

> On 25 May 2016 15:36, Joseph Myers wrote:
> > On Tue, 24 May 2016, Matt Turner wrote:
> > > -  else
> > > -    {
> > > -      if (j0 == 0x400)
> > > -	/* x is inf or NaN.  */
> > > -	return x + x;
> > > -    }
> > 
> > You're removing too much code here.  You need to keep this addition in the 
> > NaN case to ensure that signaling NaNs raise "invalid" and get converted 
> > to quiet NaNs in the process.
> 
> does this mean current test coverage is insufficient ?

Yes.  I intend to add sNaN support to libm-test.inc at some point if noone 
else gets there first; no doubt this would then show up lots of bugs in 
existing code.  Cf. 
<https://sourceware.org/ml/libc-ports/2013-04/msg00008.html>, but that 
would need completely reworking now for current libm-test.