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 /sysvipc/Versions | |
parent | b1176270deffff46db9b39645bff10fe7b8c5fbd (diff) | |
download | glibc-4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252.zip glibc-4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252.tar.gz glibc-4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252.tar.bz2 |
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 'sysvipc/Versions')
0 files changed, 0 insertions, 0 deletions