This is the mail archive of the gcc-patches@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]

PATCH: Use Intel BID library for BID


On Thu, Jun 14, 2007 at 06:30:57AM -0700, H. J. Lu wrote:
> With Intel BID library, we got 2 failures in unmodified DFP tests,
> fe-convert-1.c and fe-convert-2.c, due to different exceptions
> in Intel BID library vs. libdecnumber. The differences are
> 
> 1.  When the input value is larger than the max value that fits in the 
> destination format, it means overflow. In this case the IEEE 754R draft
> specifies that both overflow and inexact exceptions should be signaled.
> These are
> 
> CONVERT (101, d64, d32, 10.000000e96DD, FE_INEXACT)
> CONVERT (111, d128, d32, 10.000000e96DL, FE_INEXACT)
> CONVERT (121, d128, d64, 10.00000000000000E384DL, FE_INEXACT)
> 
> in testsuite/gcc.dg/dfp/fe-convert-1.c.  Libdecnumber doesn't signal
> overflow and Intel BID library does. We believe Intel BID library is
> correct.
> 
> 2. For
> 
> CONVERT (100, d, d32, 1.0e96, 0)
> CONVERT (102, d, d32, -1.0e96, 0)
> 
> in testsuite/gcc.dg/dfp/fe-convert-2.c. They expect the conversion
> results to be exact. This is not correct. The input value 1.0e96
> (or -1.0e96) is assigned the double precision value d. But this
> is not representable exactly as a double precision value, so what we
> store in d is an approximation of 1.0e96. The hex value for 1e96 is
> 
> 0x77d9d58b62cd8a5162e7f4a779f5080f1c46d01ae478b23be1178e81000000000000000000000000
> 
> which does not fit in the 53-bit significand of a double. So when the
> value stored in x, the value in x is really
> 
> 1000000000000000049861653971908893017010268485438462151574892930611988399099305815384459015356416
> 
> This is close to 10^96, but not exactly 10^96. So the conversion of
> this double to _Decimal32 is inexact (the result is indeed 10^96).
> Intel BID library will signal FE_INEXACT in both cases.
> 
> Also Intel BID library passes those tests:
> 
> #if 0
> /* These should result in fp exceptions but don't.  */
> CONVERT (xxx, d, d32, 1.0e-96, FE_UNDERFLOW|FE_INEXACT)
> CONVERT (xxx, d, d32, 0.00048828125, FE_INEXACT)  /* exact power of 2 */
> #endif
> 
> in testsuite/gcc.dg/dfp/fe-convert-2.c. I'd like to enable them at
> least for Intel BID library. I am enclosing the DFP testsuite
> modifications here.  Should I condition all those changes based on
> __DECIMAL_BID_FORMAT__?
> 
> 

Here are patches to use Intel BID library when DFP/BID is enabled.
Intel BID library is available from

http://groups.google.com/group/ia32-abi

as

http://ia32-abi.googlegroups.com/web/libbid-20070614-1.tar.bz2?gda=jqlWm0oAAABayoZq9NXPKZm1OAVN1mTGCvMcjKeqJWo_mt4fEtH5fWG1qiJ7UbTIup-M2XPURDT46id7tgvzqkE5UQ-NNYRsNIBjWWKka8cnEjFziSOZLQ

Tested on Linux/ia32 and Linux/Intel64.

There are some known issues:

1. Intel BID library isn't thread-safe nor is libdecnumber for that
matter.  There are several ways to deal with it
    a. Use local make rounding and status flags on stack in each
    intrinsic.
      Pro:
	Easy to implement.
      Cons:
	Extra performance overhead.
	DFP round/exception access functions aren't thread-safe.
    b. Use __thread on DFP round and status flags.
      Pros:
	Good runtime performance.
	Really thread-safe.
	Easy to implement in Intel BID library.
      Cons:
	May not work with static executable.
	May not work with all thread implementations.
    c.  Call a function to get rounding or status flag. Use different
	functions in single thread and multi thread executables.
      Pros:
	Relatively easy to implement.
      Cons:
	Need compiler switch to link with single thread or multi
	thread versions of functions.
	Extra performance overhead with function call when accessing
	those round/exception flags.
	May not work well with multi thread shared library.
    d.  Call a function to get rounding or status flag. Compiler
	provides a default, thread-unsafe version and users are
	free to provide a thread-safe one.
      Pros:
	Relatively easy to implement.
      Cons:
	Extra performance overhead with function call when accessing
	those round/exception flags.
	May not work on all platforms.
    e. Compile 2 version BID intrinsics. Extra for thread-safe with
       __thread.
      Pros:
	Relatively easy to implement.
      Cons:
	Need compiler switch to link with single thread or multi
	thread versions of BID intrinsics.
	May not work well with multi thread shared library.

2. Bid endian is supported, but untested.

3. DFP round/exception access functions are different from similar ones
declared in <fenv.h>. PR 32330.

4. Intel BID library has many more features gcc can use to optimize
DFP.


H.J.

Attachment: gcc-dfp-float128-3.patch
Description: Text document

Attachment: gcc-libbid-5.patch
Description: Text document

Attachment: gcc-dfp-test-1.patch
Description: Text document


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