diff options
author | Joseph Myers <joseph@codesourcery.com> | 2018-09-11 14:51:40 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2018-09-11 14:51:40 +0000 |
commit | 4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252 (patch) | |
tree | a466fe3348ca5e8b211916bc7ff4631f9b5feb6b /sysdeps/i386 | |
parent | b1176270deffff46db9b39645bff10fe7b8c5fbd (diff) | |
download | glibc-4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252.tar.gz glibc-4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252.tar.xz glibc-4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252.zip |
Remove x86_64 math_private.h asms.
The x86_64 math_private.h has asm versions of the macros to reinterpret between floating-point and integer types. This is the sort of thing we now strongly discourage; the expectation in such cases, where the generic C code gives the compiler all the information needed about the required semantics, is that you should get the compiler to do the right thing for the generic C code rather than writing an asm version. Trivial tests showed GCC generates the expected single instructions for reinterpretation from floating point to integer. In the other direction, it goes via memory when the asms don't; I asked about this in GCC bug 87236 and was advised this was deliberate for generic tuning because it was faster that way on some AMD processors (but -mtune=intel, and -Os with the latest GCC, avoid going via memory). The asms don't and can't know about those tuning details, so that's evidence that they are actually making the code worse. This patch removes the asms accordingly. Tested for x86_64. * sysdeps/x86_64/fpu/math_private.h (MOVD): Remove macro. (MOVQ): Likewise. (EXTRACT_WORDS64): Likewise. (INSERT_WORDS64): Likewise. (GET_FLOAT_WORD): Likewise. (SET_FLOAT_WORD): Likewise.
Diffstat (limited to 'sysdeps/i386')
0 files changed, 0 insertions, 0 deletions