This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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] |
On 12/20/2017 11:56 AM, Joseph Myers wrote:
On Wed, 20 Dec 2017, Patrick McGehearty wrote:I did note in the comments (fairly far down) to the patch that "For x86, tgamma showed a few values where the ulp increased to 6 (max ulp for tgamma is 5). Sparc tgamma did not show these failures."The problem isn't ulps changes, the problem is that there were test failures (missing errno setting in this case) *other than* ones for which a libm-test-ulps regeneration sufficed, and such failures always need more investigation.If the hypothesis is correct, I find it odd for get_rounding_mode to not have matching behavior with libc_fesetround for x86.Well, get_rounding_mode has previously only been used (on x86_64 / x86) in interfaces such as strtod / printf (for which it was originally added), for which results when the SSE and x87 rounding modes are different don't matter. Whereas libm functions can be called internally when those modes are different, as part of optimizations that rely on knowing which rounding mode is relevant for computations in a particular type and avoiding changing the other part of the floating-point state. Thus, you need type-specific interfaces in libm (libc_fegetround{,f,l}) whereas you don't in strtod / printf. (Of course this doesn't make any difference for architectures other than x86_64 / x86, because that's the only case where you have two different sets of floating-point state at all.)
Summary of results:Tested replacing get_rounding_mode and libc_fesetround only when not in FE_TONEAREST
mode with SET_RESTORE_ROUND (FE_TONEAREST).The tgamma failures disappeared, giving strong support to Joseph's hypothesis.
For x86, there is roughly a 5% performance cost which would be tolerable. Unfortunately, for Sparc, there is a 76% performance cost which isless tolerable. When Sparc changes the rounding mode, the instruction pipeline is flushed which has a non-trival cost. I suspect the performance cost will be higher on all platforms which have a high cost for changing the rounding mode.
Alternatives: 1) Accept the current behavior. - least work. 2) Just use SET_RESTORE_ROUND for now. - almost no additional work, but slower on some platforms. 3) Define a macro either within e_exp.c or in an include file that selects get_rounding_mode and libc_fesetround for all platforms except x86. It selects SET_RESTORE_ROUND for x86. Putting platform specific macros inside ieee754 branch seems undesirable, but I thought I should mention it as a possibility. 4) Put the SET_RESTORE_ROUND version of e_exp.c as an x86 specific version in the sysdeps tree and the get_rounding_mode version in the ieee754 part of the tree. Some more work when I'm ready to go on winter break. :-) Or, do (2) now and maybe (4) later. Also, as an separate experiment, I tested doubling the size of TBL[] again to use step sizes of 1/128 instead of 1/64. It reduces the error rate from 16.1/10000 to 9.7/10000. It does not remove the 1 bit errors in the current "make check" tests. To fix those will likely require increasing the size of TBL2[]. For my next patch I'm going to go with the larger TBL[] size unless someone objects. Might as well reduce even small errors when we can. - patrick ps Apologies for continuing to accidentally send incomplete messaging while composing. I apparently have an unconscious trained reflex to type ^S whenever I pause for thought. That is beneficial for editors that interpret that as "save file". No so much on mail programs that interpret ^S as "send file". I will try to remember to compose outside of mail in the future and then copy/paste into the mailer.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |