aboutsummaryrefslogtreecommitdiff
path: root/sysvipc/Versions
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2018-09-11 14:51:40 +0000
committerJoseph Myers <joseph@codesourcery.com>2018-09-11 14:51:40 +0000
commit4e7fbdd7c2884e8909ea8f2f59d52f7d0c699252 (patch)
treea466fe3348ca5e8b211916bc7ff4631f9b5feb6b /sysvipc/Versions
parentb1176270deffff46db9b39645bff10fe7b8c5fbd (diff)
downloadglibc-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