Re: [PATCH] i386: move ULPs to i686 and regenerate new ones for i586

[Aurelien Jarno <aurelien at aurel32 dot net>]

On 2015-12-04 13:18, Aurelien Jarno wrote:
> On 2015-12-03 22:28, Joseph Myers wrote:
> > On Thu, 3 Dec 2015, Aurelien Jarno wrote:
> > 
> > > The i386 ULPs are actually the i686 ones. The i586 results are slightly
> > > less precise. Therefore move the current ULPs to the i386/i686 directory
> > > and generate i586 ones for the i386 directory.
> > 
> > Are you sure they are i686 ones rather than actually i686+SSE2 (does 
> > --disable-multi-arch make any difference)?
> 
> You are actually correct, the current sysdeps/i386/fpu/libm-test-ulps
> file corresponds to the i686+SSE2 ULPs.
> 
> Also the i586 and i686 ULPs are actually the same.
> 
> > > Note: In theory we should even put the i486 ULPs in the i386 directory
> > > and put the i586 ones in the i386/i586 directory. Not sure it is worth
> > > it.
> > 
> > There are no i586-specific libm function implementations, so there should 
> > be no difference in ulps between glibc built for i486 and i586.
> > 
> > If test inputs can be found that, built for i686, generate the higher ulps 
> > seen when building for pre-i686, that would reduce the number of variant 
> > ulps files needing regeneration.
> 
> Ok, I'll try that, but between i686 and i686+SSE2.

The difference between the two only affects float ULPs for the cos, sin,
ctan and ctanh functions. The difference can be explained by the fact
that the SSE2 version of sinf and cosf basically convert the single
precision input into double precision, do all the computation in double
precision, and convert back the result to single precision.

I am therefore afraid we won't be able to find a case were the i686 and
SSE2 versions produce the same error.


Interestingly it also seems that the i586 ULPs differ between an AMD and
Intel CPU for the cacos_downward, cacos_towardzero and cacosh_downward 
double precision functions. Here is one of the failure on an AMD CPU:

  Failure: Test: Real part of: cacos_downward (1.0 + 0x1.fp-129 i)
  Result:
   is:          5.33563527698223236644e-20   0x1.f7efbeb8d4f100000000p-65
   should be:   5.33563527698223357014e-20   0x1.f7efbeb8d4f120000000p-65
   difference:  1.20370621524202240815e-35   0x1.00000000000000000000p-116
   ulp       :  2.0000
   max.ulp   :  1.0000

However the high precision result (at least the one in libm-test.inc) is
5.335635276982233498398987585285818977930e-20L. The expected result there
seems to me rounded upward and not downward, and thus the actual result
seems to be the correct one. Where am I wrong?

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net