I noticed fairly recently that after a lot of AVX vectorized code I was utilizing the scalar sincosf in libm for the remainder. I found it particularly odd that this code was being outperformed by SSE4 variations of the code, and later traced the issue to be the fact that sincosf is utilizing legacy SSE instructions in what was otherwise AVX accelerated code. This was causing a sizable transition penalty between AVX and SSE, as the code calling the sincosf function was utilizing ymm* (AVX) registers. I added a hardcoded vzeroupper() to fix this transition penalty, but having a VEX coded version to jump to might be of benefit for some workloads. Arguably I shouldn't be utilizing the scalar instructions at all for the remainder, and that's probably one other possible solution, but I thought I'd file this all the same.
Can you add the testcase and compilation commands?
Created attachment 9469 [details] Slower AVX example Compile this with -mavx & then compile it with -msse4. The -msse4 version will be faster as it's not hitting the SSE to AVX register transition penalty.
Just attached a pretty basic scalar version, it's about twice as slow with -mavx as it is with -msse4.
It may help to increase the iterations a bit more by modifying numvals to be 200*9000 or so. After doing that, even with -O3, it's clear we're hitting that penalty: adam@eggsbenedict ~ $ gcc -mavx test_sincos.c -o test.out -lm -O3 adam@eggsbenedict ~ $ time ./test.out real 0m0.174s user 0m0.171s sys 0m0.002s adam@eggsbenedict ~ $ gcc -msse4 test_sincos.c -o test.out -lm -O3 adam@eggsbenedict ~ $ time ./test.out real 0m0.069s user 0m0.064s sys 0m0.004s
Thanks. Investigation shows that it is degradation from 2.22 to 2.23 releases. Simplified testcase is #include <math.h> #define NUM 9000*1000 float valsA[NUM]; float a[NUM]; int main(void) { int i; for (i = 0; i < NUM; ++i) { a[i] += sinf(valsA[i]); } return (int)a[NUM-1]; }
Looks like performance drop caused by commit f3dcae82d54e5097e18e1d6ef4ff55c2ea4e621e Save and restore vector registers in x86-64 ld.so because it adds save/restore of YMM registers (with AVX instructions) before call to sinf() implemented in SSE.
See: https://sourceware.org/ml/libc-alpha/2016-08/msg00741.html But it only works for machines supporting XGETBV with ECX == 1.
(In reply to Adam Stylinski from comment #2) > Created attachment 9469 [details] > Slower AVX example > > Compile this with -mavx & then compile it with -msse4. The -msse4 version > will be faster as it's not hitting the SSE to AVX register transition > penalty. You can avoid slowdown also using "-Wl,-z,now".
Dup *** This bug has been marked as a duplicate of bug 20508 ***
Created attachment 9476 [details] attachment-83016-0.html Interesting, I will have to try that link flag. What is the reason for that working? Everything I can find about that flag is for hardening binaries to prevent others from writing into the global offset table. On Aug 25, 2016 4:03 PM, "andrew.n.senkevich at gmail dot com" < sourceware-bugzilla@sourceware.org> wrote: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20495 > > --- Comment #8 from Andrew Senkevich <andrew.n.senkevich at gmail dot com> --- > (In reply to Adam Stylinski from comment #2) > > Created attachment 9469 [details] > > Slower AVX example > > > > Compile this with -mavx & then compile it with -msse4. The -msse4 version > > will be faster as it's not hitting the SSE to AVX register transition > > penalty. > > You can avoid slowdown also using "-Wl,-z,now". > > -- > You are receiving this mail because: > You reported the bug.
(In reply to Adam Stylinski from comment #10) > Created attachment 9476 [details] > attachment-83016-0.html > > Interesting, I will have to try that link flag. What is the reason for that > working? Everything I can find about that flag is for hardening binaries to > prevent others from writing into the global offset table. > > On Aug 25, 2016 4:03 PM, "andrew.n.senkevich at gmail dot com" < > sourceware-bugzilla@sourceware.org> wrote: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20495 > > > > --- Comment #8 from Andrew Senkevich <andrew.n.senkevich at gmail dot > com> --- > > (In reply to Adam Stylinski from comment #2) > > > Created attachment 9469 [details] > > > Slower AVX example > > > > > > Compile this with -mavx & then compile it with -msse4. The -msse4 > version > > > will be faster as it's not hitting the SSE to AVX register transition > > > penalty. > > > > You can avoid slowdown also using "-Wl,-z,now". > > > > -- > > You are receiving this mail because: > > You reported the bug. Current issue because of AVX in _dl_runtime_resolve() during the first call of SSE sinf(). From man ld: -z now When generating an executable or shared library, mark it to tell the dynamic linker to resolve all symbols when the program is started, or when the shared library is linked to using dlopen, instead of deferring function call resolution to the point when the function is first called. So it may help or may not. Helps for reduced but not for original test.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, hjl/x86/xgetbv has been created at 99143e37c1186c765da5b6e892ddaff0b3719f9f (commit) - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=99143e37c1186c765da5b6e892ddaff0b3719f9f commit 99143e37c1186c765da5b6e892ddaff0b3719f9f Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Aug 23 09:09:32 2016 -0700 X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508] There is transition penalty when SSE instructions are mixed with 256-bit AVX or 512-bit AVX512 load instructions. Since _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM registers, there is transition penalty when SSE instructions are used with lazy binding on AVX and AVX512 processors. To avoid SSE transition penalty, if only the lower 128 bits of the first 8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers with the zero upper bits. For AVX and AVX512 processors which support XGETBV with ECX == 1, we can use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers or the upper 256 bits of ZMM registers are zero. We can restore only the non-zero portion of vector registers with AVX/AVX512 load instructions which will zero-extend upper bits of vector registers. This patch adds _dl_runtime_resolve_sse_vex which saves and restores XMM registers with 128-bit AVX store/load instructions. It is used to preserve YMM/ZMM registers when only the lower 128 bits are non-zero. _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so that we store and load only the non-zero portion of vector registers. This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 when only the lower 128 bits of vector registers are used. _dl_runtime_resolve_avx_slow is added and used for AVX processors which don't upport XGETBV with ECX == 1. Since there is no SSE transition penalty on AVX512 processors which don't support XGETBV with ECX == 1, _dl_runtime_resolve_avx512_slow isn't provided. [BZ #20495] [BZ #20508] * sysdeps/x86/cpu-features.c (init_cpu_features): For Intel processors, set Use_dl_runtime_resolve_slow and set Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1. * sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt): New. (bit_arch_Use_dl_runtime_resolve_slow): Likewise. (index_arch_Use_dl_runtime_resolve_opt): Likewise. (index_arch_Use_dl_runtime_resolve_slow): Likewise. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use _dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt if Use_dl_runtime_resolve_opt is set. Use _dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set. * sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>. (_dl_runtime_resolve_opt): New. Defined for AVX and AVX512. (_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow): New. (_dl_runtime_resolve_opt): Likewise. (_dl_runtime_profile): Define only if _dl_runtime_profile is defined. -----------------------------------------------------------------------
This is not an exact duplicate, it needs a separate fix.
(In reply to Florian Weimer from comment #13) > This is not an exact duplicate, it needs a separate fix. The fix for PR 20508 is extended to cover this: https://sourceware.org/ml/libc-alpha/2016-08/msg00803.html
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, hjl/x86/xgetbv has been created at fdb9777e1d770446972f46a80ebfa59d522a93f1 (commit) - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fdb9777e1d770446972f46a80ebfa59d522a93f1 commit fdb9777e1d770446972f46a80ebfa59d522a93f1 Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Aug 23 09:09:32 2016 -0700 X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508] There is transition penalty when SSE instructions are mixed with 256-bit AVX or 512-bit AVX512 load instructions. Since _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM registers, there is transition penalty when SSE instructions are used with lazy binding on AVX and AVX512 processors. To avoid SSE transition penalty, if only the lower 128 bits of the first 8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers with the zero upper bits. For AVX and AVX512 processors which support XGETBV with ECX == 1, we can use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers or the upper 256 bits of ZMM registers are zero. We can restore only the non-zero portion of vector registers with AVX/AVX512 load instructions which will zero-extend upper bits of vector registers. This patch adds _dl_runtime_resolve_sse_vex which saves and restores XMM registers with 128-bit AVX store/load instructions. It is used to preserve YMM/ZMM registers when only the lower 128 bits are non-zero. _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so that we store and load only the non-zero portion of vector registers. This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 when only the lower 128 bits of vector registers are used. _dl_runtime_resolve_avx_slow is added and used for AVX processors which don't support XGETBV with ECX == 1. Since there is no SSE transition penalty on AVX512 processors which don't support XGETBV with ECX == 1, _dl_runtime_resolve_avx512_slow isn't provided. [BZ #20495] [BZ #20508] * sysdeps/x86/cpu-features.c (init_cpu_features): For Intel processors, set Use_dl_runtime_resolve_slow and set Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1. * sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt): New. (bit_arch_Use_dl_runtime_resolve_slow): Likewise. (index_arch_Use_dl_runtime_resolve_opt): Likewise. (index_arch_Use_dl_runtime_resolve_slow): Likewise. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use _dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt if Use_dl_runtime_resolve_opt is set. Use _dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set. * sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>. (_dl_runtime_resolve_opt): New. Defined for AVX and AVX512. (_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow): New. (_dl_runtime_resolve_opt): Likewise. (_dl_runtime_profile): Define only if _dl_runtime_profile is defined. -----------------------------------------------------------------------
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604 (commit) from a0d47f487fe250c63cc21e9608b85bc02dc2a006 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604 commit fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604 Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Sep 6 08:50:55 2016 -0700 X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508] There is transition penalty when SSE instructions are mixed with 256-bit AVX or 512-bit AVX512 load instructions. Since _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM registers, there is transition penalty when SSE instructions are used with lazy binding on AVX and AVX512 processors. To avoid SSE transition penalty, if only the lower 128 bits of the first 8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers with the zero upper bits. For AVX and AVX512 processors which support XGETBV with ECX == 1, we can use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers or the upper 256 bits of ZMM registers are zero. We can restore only the non-zero portion of vector registers with AVX/AVX512 load instructions which will zero-extend upper bits of vector registers. This patch adds _dl_runtime_resolve_sse_vex which saves and restores XMM registers with 128-bit AVX store/load instructions. It is used to preserve YMM/ZMM registers when only the lower 128 bits are non-zero. _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so that we store and load only the non-zero portion of vector registers. This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 when only the lower 128 bits of vector registers are used. _dl_runtime_resolve_avx_slow is added and used for AVX processors which don't support XGETBV with ECX == 1. Since there is no SSE transition penalty on AVX512 processors which don't support XGETBV with ECX == 1, _dl_runtime_resolve_avx512_slow isn't provided. [BZ #20495] [BZ #20508] * sysdeps/x86/cpu-features.c (init_cpu_features): For Intel processors, set Use_dl_runtime_resolve_slow and set Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1. * sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt): New. (bit_arch_Use_dl_runtime_resolve_slow): Likewise. (index_arch_Use_dl_runtime_resolve_opt): Likewise. (index_arch_Use_dl_runtime_resolve_slow): Likewise. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use _dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt if Use_dl_runtime_resolve_opt is set. Use _dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set. * sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>. (_dl_runtime_resolve_opt): New. Defined for AVX and AVX512. (_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow): New. (_dl_runtime_resolve_opt): Likewise. (_dl_runtime_profile): Define only if _dl_runtime_profile is defined. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 25 ++++++++++ sysdeps/x86/cpu-features.c | 14 +++++ sysdeps/x86/cpu-features.h | 6 ++ sysdeps/x86_64/dl-machine.h | 24 ++++++++- sysdeps/x86_64/dl-trampoline.S | 20 ++++++++ sysdeps/x86_64/dl-trampoline.h | 104 +++++++++++++++++++++++++++++++++++++++- 6 files changed, 190 insertions(+), 3 deletions(-)
Is this fixed by the September commit to master, or not?
Not sure, how do I point my GCC to target the new master of glibc without actually replacing my distro's glibc? If anyone else could test this, the example I posted is pretty basic: adam@Crushinator:~$ gcc -mavx test_sincos.c -o test.out -lm -O3 adam@Crushinator:~$ time ./test.out real 0m0.083s user 0m0.080s sys 0m0.000s adam@Crushinator:~$ gcc -msse4 testsincos.c -o test.out -lm -O3 adam@Crushinator:~$ time ./test.out real 0m0.029s user 0m0.027s sys 0m0.000s Just bump NUMVALS up to something arbitrarily high.
(In reply to Adam Stylinski from comment #18) > Not sure, how do I point my GCC to target the new master of glibc without > actually replacing my distro's glibc? If you build glibc from source, you'll get a script, testrun.sh, which runs its argument against the newly built glibc: https://sourceware.org/glibc/wiki/Testing/Builds
(In reply to Florian Weimer from comment #19) > (In reply to Adam Stylinski from comment #18) > > Not sure, how do I point my GCC to target the new master of glibc without > > actually replacing my distro's glibc? > > If you build glibc from source, you'll get a script, testrun.sh, which runs > its argument against the newly built glibc: > > https://sourceware.org/glibc/wiki/Testing/Builds Yes, this definitely fixes it.
Marking as fixed. Hoping 2.25 gets into my distro, soon.
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, release/2.24/master has been updated via 4b8790c81c1a7b870a43810ec95e08a2e501123d (commit) from 2d16e81babd1d7b66d10cec0bc6d6d86a7e0c95e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=4b8790c81c1a7b870a43810ec95e08a2e501123d commit 4b8790c81c1a7b870a43810ec95e08a2e501123d Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Sep 6 08:50:55 2016 -0700 X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508] There is transition penalty when SSE instructions are mixed with 256-bit AVX or 512-bit AVX512 load instructions. Since _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM registers, there is transition penalty when SSE instructions are used with lazy binding on AVX and AVX512 processors. To avoid SSE transition penalty, if only the lower 128 bits of the first 8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers with the zero upper bits. For AVX and AVX512 processors which support XGETBV with ECX == 1, we can use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers or the upper 256 bits of ZMM registers are zero. We can restore only the non-zero portion of vector registers with AVX/AVX512 load instructions which will zero-extend upper bits of vector registers. This patch adds _dl_runtime_resolve_sse_vex which saves and restores XMM registers with 128-bit AVX store/load instructions. It is used to preserve YMM/ZMM registers when only the lower 128 bits are non-zero. _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so that we store and load only the non-zero portion of vector registers. This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 when only the lower 128 bits of vector registers are used. _dl_runtime_resolve_avx_slow is added and used for AVX processors which don't support XGETBV with ECX == 1. Since there is no SSE transition penalty on AVX512 processors which don't support XGETBV with ECX == 1, _dl_runtime_resolve_avx512_slow isn't provided. [BZ #20495] [BZ #20508] * sysdeps/x86/cpu-features.c (init_cpu_features): For Intel processors, set Use_dl_runtime_resolve_slow and set Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1. * sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt): New. (bit_arch_Use_dl_runtime_resolve_slow): Likewise. (index_arch_Use_dl_runtime_resolve_opt): Likewise. (index_arch_Use_dl_runtime_resolve_slow): Likewise. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use _dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt if Use_dl_runtime_resolve_opt is set. Use _dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set. * sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>. (_dl_runtime_resolve_opt): New. Defined for AVX and AVX512. (_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow): New. (_dl_runtime_resolve_opt): Likewise. (_dl_runtime_profile): Define only if _dl_runtime_profile is defined. (cherry picked from commit fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604) ----------------------------------------------------------------------- Summary of changes: ChangeLog | 25 ++++++++++ sysdeps/x86/cpu-features.c | 14 +++++ sysdeps/x86/cpu-features.h | 6 ++ sysdeps/x86_64/dl-machine.h | 24 ++++++++- sysdeps/x86_64/dl-trampoline.S | 20 ++++++++ sysdeps/x86_64/dl-trampoline.h | 104 +++++++++++++++++++++++++++++++++++++++- 6 files changed, 190 insertions(+), 3 deletions(-)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, gentoo/2.24 has been updated via b73ec923c79ab493a9265930a45800391329571a (commit) via 04c5f782796052de9d06975061eb3376ccbcbdb1 (commit) via 9b34c1494d8e61bb3d718e2ea83b856030476737 (commit) via 2afb8a945ddc104c5ef9aa61f32427c19b681232 (commit) via df13b9c22a0fb690a0ab9dd4af163ae3c459d975 (commit) via b4391b0c7def246a4503db1af683122681c12a56 (commit) via 0d5f4a32a34f048b35360a110a0e6d1c87e3eced (commit) via 0ab02a62e42e63b058e7a4e160dbe51762ef2c46 (commit) via 901db98f36690e4743feefd985c6ba2d7fd19813 (commit) from caafe2b2612be88046d7bad4da42dbc2b07fbcd7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b73ec923c79ab493a9265930a45800391329571a commit b73ec923c79ab493a9265930a45800391329571a Author: Aurelien Jarno <aurelien@aurel32.net> Date: Tue Aug 2 09:18:59 2016 +0200 alpha: fix trunc for big input values The alpha specific version of trunc and truncf always add and subtract 0x1.0p23 or 0x1.0p52 even for big values. This causes this kind of errors in the testsuite: Failure: Test: trunc_towardzero (0x1p107) Result: is: 1.6225927682921334e+32 0x1.fffffffffffffp+106 should be: 1.6225927682921336e+32 0x1.0000000000000p+107 difference: 1.8014398509481984e+16 0x1.0000000000000p+54 ulp : 0.5000 max.ulp : 0.0000 Change this by returning the input value when its absolute value is greater than 0x1.0p23 or 0x1.0p52. NaN have to go through the add and subtract operations to get possibly silenced. Finally remove the code to handle inexact exception, trunc should never generate such an exception. Changelog: * sysdeps/alpha/fpu/s_trunc.c (__trunc): Return the input value when its absolute value is greater than 0x1.0p52. [_IEEE_FP_INEXACT] Remove. * sysdeps/alpha/fpu/s_truncf.c (__truncf): Return the input value when its absolute value is greater than 0x1.0p23. [_IEEE_FP_INEXACT] Remove. (cherry picked from commit b74d259fe793499134eb743222cd8dd7c74a31ce) (cherry picked from commit e6eab16cc302e6c42f79e1af02ce98ebb9a783bc) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=04c5f782796052de9d06975061eb3376ccbcbdb1 commit 04c5f782796052de9d06975061eb3376ccbcbdb1 Author: Aurelien Jarno <aurelien@aurel32.net> Date: Tue Aug 2 09:18:59 2016 +0200 alpha: fix rint on sNaN input The alpha version of rint wrongly return sNaN for sNaN input. Fix that by checking for NaN and by returning the input value added with itself in that case. Changelog: * sysdeps/alpha/fpu/s_rint.c (__rint): Add argument with itself when it is a NaN. * sysdeps/alpha/fpu/s_rintf.c (__rintf): Likewise. (cherry picked from commit cb7f9d63b921ea1a1cbb4ab377a8484fd5da9a2b) (cherry picked from commit 8eb9a92e0522f2d4f2d4167df919d066c85d3408) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9b34c1494d8e61bb3d718e2ea83b856030476737 commit 9b34c1494d8e61bb3d718e2ea83b856030476737 Author: Aurelien Jarno <aurelien@aurel32.net> Date: Tue Aug 2 09:18:59 2016 +0200 alpha: fix floor on sNaN input The alpha version of floor wrongly return sNaN for sNaN input. Fix that by checking for NaN and by returning the input value added with itself in that case. Finally remove the code to handle inexact exception, floor should never generate such an exception. Changelog: * sysdeps/alpha/fpu/s_floor.c (__floor): Add argument with itself when it is a NaN. [_IEEE_FP_INEXACT] Remove. * sysdeps/alpha/fpu/s_floorf.c (__floorf): Likewise. (cherry picked from commit 65cc568cf57156e5230db9a061645e54ff028a41) (cherry picked from commit 1912cc082df4739c2388c375f8d486afdaa7d49b) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2afb8a945ddc104c5ef9aa61f32427c19b681232 commit 2afb8a945ddc104c5ef9aa61f32427c19b681232 Author: Aurelien Jarno <aurelien@aurel32.net> Date: Tue Aug 2 09:18:59 2016 +0200 alpha: fix ceil on sNaN input The alpha version of ceil wrongly return sNaN for sNaN input. Fix that by checking for NaN and by returning the input value added with itself in that case. Finally remove the code to handle inexact exception, ceil should never generate such an exception. Changelog: * sysdeps/alpha/fpu/s_ceil.c (__ceil): Add argument with itself when it is a NaN. [_IEEE_FP_INEXACT] Remove. * sysdeps/alpha/fpu/s_ceilf.c (__ceilf): Likewise. (cherry picked from commit 062e53c195b4a87754632c7d51254867247698b4) (cherry picked from commit 3eff6f84311d2679a58a637e3be78b4ced275762) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=df13b9c22a0fb690a0ab9dd4af163ae3c459d975 commit df13b9c22a0fb690a0ab9dd4af163ae3c459d975 Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Sep 6 08:50:55 2016 -0700 X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508] There is transition penalty when SSE instructions are mixed with 256-bit AVX or 512-bit AVX512 load instructions. Since _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM registers, there is transition penalty when SSE instructions are used with lazy binding on AVX and AVX512 processors. To avoid SSE transition penalty, if only the lower 128 bits of the first 8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers with the zero upper bits. For AVX and AVX512 processors which support XGETBV with ECX == 1, we can use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers or the upper 256 bits of ZMM registers are zero. We can restore only the non-zero portion of vector registers with AVX/AVX512 load instructions which will zero-extend upper bits of vector registers. This patch adds _dl_runtime_resolve_sse_vex which saves and restores XMM registers with 128-bit AVX store/load instructions. It is used to preserve YMM/ZMM registers when only the lower 128 bits are non-zero. _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so that we store and load only the non-zero portion of vector registers. This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 when only the lower 128 bits of vector registers are used. _dl_runtime_resolve_avx_slow is added and used for AVX processors which don't support XGETBV with ECX == 1. Since there is no SSE transition penalty on AVX512 processors which don't support XGETBV with ECX == 1, _dl_runtime_resolve_avx512_slow isn't provided. [BZ #20495] [BZ #20508] * sysdeps/x86/cpu-features.c (init_cpu_features): For Intel processors, set Use_dl_runtime_resolve_slow and set Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1. * sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt): New. (bit_arch_Use_dl_runtime_resolve_slow): Likewise. (index_arch_Use_dl_runtime_resolve_opt): Likewise. (index_arch_Use_dl_runtime_resolve_slow): Likewise. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use _dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt if Use_dl_runtime_resolve_opt is set. Use _dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set. * sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>. (_dl_runtime_resolve_opt): New. Defined for AVX and AVX512. (_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow): New. (_dl_runtime_resolve_opt): Likewise. (_dl_runtime_profile): Define only if _dl_runtime_profile is defined. (cherry picked from commit fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b4391b0c7def246a4503db1af683122681c12a56 commit b4391b0c7def246a4503db1af683122681c12a56 Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Sep 6 08:50:55 2016 -0700 X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508] There is transition penalty when SSE instructions are mixed with 256-bit AVX or 512-bit AVX512 load instructions. Since _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM registers, there is transition penalty when SSE instructions are used with lazy binding on AVX and AVX512 processors. To avoid SSE transition penalty, if only the lower 128 bits of the first 8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers with the zero upper bits. For AVX and AVX512 processors which support XGETBV with ECX == 1, we can use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers or the upper 256 bits of ZMM registers are zero. We can restore only the non-zero portion of vector registers with AVX/AVX512 load instructions which will zero-extend upper bits of vector registers. This patch adds _dl_runtime_resolve_sse_vex which saves and restores XMM registers with 128-bit AVX store/load instructions. It is used to preserve YMM/ZMM registers when only the lower 128 bits are non-zero. _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so that we store and load only the non-zero portion of vector registers. This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 when only the lower 128 bits of vector registers are used. _dl_runtime_resolve_avx_slow is added and used for AVX processors which don't support XGETBV with ECX == 1. Since there is no SSE transition penalty on AVX512 processors which don't support XGETBV with ECX == 1, _dl_runtime_resolve_avx512_slow isn't provided. [BZ #20495] [BZ #20508] * sysdeps/x86/cpu-features.c (init_cpu_features): For Intel processors, set Use_dl_runtime_resolve_slow and set Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1. * sysdeps/x86/cpu-features.h (bit_arch_Use_dl_runtime_resolve_opt): New. (bit_arch_Use_dl_runtime_resolve_slow): Likewise. (index_arch_Use_dl_runtime_resolve_opt): Likewise. (index_arch_Use_dl_runtime_resolve_slow): Likewise. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use _dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt if Use_dl_runtime_resolve_opt is set. Use _dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set. * sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>. (_dl_runtime_resolve_opt): New. Defined for AVX and AVX512. (_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow): New. (_dl_runtime_resolve_opt): Likewise. (_dl_runtime_profile): Define only if _dl_runtime_profile is defined. (cherry picked from commit fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604) (cherry picked from commit 4b8790c81c1a7b870a43810ec95e08a2e501123d) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0d5f4a32a34f048b35360a110a0e6d1c87e3eced commit 0d5f4a32a34f048b35360a110a0e6d1c87e3eced Author: Aurelien Jarno <aurelien@aurel32.net> Date: Thu Nov 24 12:10:13 2016 +0100 x86_64: fix static build of __memcpy_chk for compilers defaulting to PIC/PIE When glibc is compiled with gcc 6.2 that has been configured with to default to PIC/PIE, the static version of __memcpy_chk is not built, as the test is done on PIC instead of SHARED. Fix the test to check for SHARED, like it is done for similar functions like memmove_chk. Changelog: * sysdeps/x86_64/memcpy_chk.S (__memcpy_chk): Check for SHARED instead of PIC. (cherry picked from commit 380ec16d62f459d5a28cfc25b7b20990c45e1cc9) (cherry picked from commit 2d16e81babd1d7b66d10cec0bc6d6d86a7e0c95e) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0ab02a62e42e63b058e7a4e160dbe51762ef2c46 commit 0ab02a62e42e63b058e7a4e160dbe51762ef2c46 Author: Maciej W. Rozycki <macro@imgtec.com> Date: Thu Nov 17 19:15:51 2016 +0000 MIPS: Add `.insn' to ensure a text label is defined as code not data Avoid a build error with microMIPS compilation and recent versions of GAS which complain if a branch targets a label which is marked as data rather than microMIPS code: ../sysdeps/mips/mips32/crti.S: Assembler messages: ../sysdeps/mips/mips32/crti.S:72: Error: branch to a symbol in another ISA mode make[2]: *** [.../csu/crti.o] Error 1 as commit 9d862524f6ae ("MIPS: Verify the ISA mode and alignment of branch and jump targets") closed a hole in branch processing, making relocation calculation respect the ISA mode of the symbol referred. This allowed diagnosing the situation where an attempt is made to pass control from code assembled for one ISA mode to code assembled for a different ISA mode and either relaxing the branch to a cross-mode jump or if that is not possible, then reporting this as an error rather than letting such code build and then fail unpredictably at the run time. This however requires the correct annotation of branch targets as code, because the ISA mode is not relevant for data symbols and is therefore not recorded for them. The `.insn' pseudo-op is used for this purpose and has been supported by GAS since: Wed Feb 12 14:36:29 1997 Ian Lance Taylor <ian@cygnus.com> * config/tc-mips.c (mips_pseudo_table): Add "insn". (s_insn): New static function. * doc/c-mips.texi: Document .insn. so there has been no reason to avoid it where required. More recently this pseudo-op has been documented, by the microMIPS architecture specification[1][2], as required for the correct interpretation of any code label which is not followed by an actual instruction in an assembly source. Use it in our crti.S files then, to mark that the trailing label there with no instructions following is indeed not a code bug and the branch is legitimate. References: [1] "MIPS Architecture for Programmers, Volume II-B: The microMIPS32 Instruction Set", MIPS Technologies, Inc., Document Number: MD00582, Revision 5.04, January 15, 2014, Section 7.1 "Assembly-Level Compatibility", p. 533 [2] "MIPS Architecture for Programmers, Volume II-B: The microMIPS64 Instruction Set", MIPS Technologies, Inc., Document Number: MD00594, Revision 5.04, January 15, 2014, Section 8.1 "Assembly-Level Compatibility", p. 623 2016-11-23 Matthew Fortune <Matthew.Fortune@imgtec.com> Maciej W. Rozycki <macro@imgtec.com> * sysdeps/mips/mips32/crti.S (_init): Add `.insn' pseudo-op at `.Lno_weak_fn' label. * sysdeps/mips/mips64/n32/crti.S (_init): Likewise. * sysdeps/mips/mips64/n64/crti.S (_init): Likewise. (cherry picked from commit cfaf1949ff1f8336b54c43796d0e2531bc8a40a2) (cherry picked from commit 65a2b63756a4d622b938910d582d8b807c471c9a) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=901db98f36690e4743feefd985c6ba2d7fd19813 commit 901db98f36690e4743feefd985c6ba2d7fd19813 Author: Adhemerval Zanella <adhemerval.zanella@linaro.org> Date: Mon Nov 21 11:06:15 2016 -0200 Fix writes past the allocated array bounds in execvpe (BZ#20847) This patch fixes an invalid write out or stack allocated buffer in 2 places at execvpe implementation: 1. On 'maybe_script_execute' function where it allocates the new argument list and it does not account that a minimum of argc plus 3 elements (default shell path, script name, arguments, and ending null pointer) should be considered. The straightforward fix is just to take account of the correct list size on argument copy. 2. On '__execvpe' where the executable file name lenght may not account for ending '\0' and thus subsequent path creation may write past array bounds because it requires to add the terminating null. The fix is to change how to calculate the executable name size to add the final '\0' and adjust the rest of the code accordingly. As described in GCC bug report 78433 [1], these issues were masked off by GCC because it allocated several bytes more than necessary so that many off-by-one bugs went unnoticed. Checked on x86_64 with a latest GCC (7.0.0 20161121) with -O3 on CFLAGS. [BZ #20847] * posix/execvpe.c (maybe_script_execute): Remove write past allocated array bounds. (__execvpe): Likewise. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78433 (cherry picked from commit d174436712e3cabce70d6cd771f177b6fe0e097b) ----------------------------------------------------------------------- Summary of changes: ChangeLog | 25 ++++++++++ posix/execvpe.c | 15 ++++-- sysdeps/alpha/fpu/s_ceil.c | 7 +-- sysdeps/alpha/fpu/s_ceilf.c | 7 +-- sysdeps/alpha/fpu/s_floor.c | 7 +-- sysdeps/alpha/fpu/s_floorf.c | 7 +-- sysdeps/alpha/fpu/s_rint.c | 3 + sysdeps/alpha/fpu/s_rintf.c | 3 + sysdeps/alpha/fpu/s_trunc.c | 7 +-- sysdeps/alpha/fpu/s_truncf.c | 7 +-- sysdeps/mips/mips32/crti.S | 1 + sysdeps/mips/mips64/n32/crti.S | 1 + sysdeps/mips/mips64/n64/crti.S | 1 + sysdeps/x86/cpu-features.c | 14 +++++ sysdeps/x86/cpu-features.h | 6 ++ sysdeps/x86_64/dl-machine.h | 24 ++++++++- sysdeps/x86_64/dl-trampoline.S | 20 ++++++++ sysdeps/x86_64/dl-trampoline.h | 104 +++++++++++++++++++++++++++++++++++++++- sysdeps/x86_64/memcpy_chk.S | 2 +- 19 files changed, 228 insertions(+), 33 deletions(-)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, hjl/pr21258/2.23 has been created at 883cadc5543ffd3a4537498b44c782ded8a4a4e8 (commit) - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=883cadc5543ffd3a4537498b44c782ded8a4a4e8 commit 883cadc5543ffd3a4537498b44c782ded8a4a4e8 Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Mar 21 10:59:31 2017 -0700 x86-64: Improve branch predication in _dl_runtime_resolve_avx512_opt [BZ #21258] On Skylake server, _dl_runtime_resolve_avx512_opt is used to preserve the first 8 vector registers. The code layout is if only %xmm0 - %xmm7 registers are used preserve %xmm0 - %xmm7 registers if only %ymm0 - %ymm7 registers are used preserve %ymm0 - %ymm7 registers preserve %zmm0 - %zmm7 registers Branch predication always executes the fallthrough code path to preserve %zmm0 - %zmm7 registers speculatively, even though only %xmm0 - %xmm7 registers are used. This leads to lower CPU frequency on Skylake server. This patch changes the fallthrough code path to preserve %xmm0 - %xmm7 registers instead: if whole %zmm0 - %zmm7 registers are used preserve %zmm0 - %zmm7 registers if only %ymm0 - %ymm7 registers are used preserve %ymm0 - %ymm7 registers preserve %xmm0 - %xmm7 registers Tested on Skylake server. [BZ #21258] * sysdeps/x86_64/dl-trampoline.S (_dl_runtime_resolve_opt): Define only if _dl_runtime_resolve is defined to _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_opt): Fallthrough to _dl_runtime_resolve_sse_vex. (cherry picked from commit c15f8eb50cea7ad1a4ccece6e0982bf426d52c00) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=83037ea1d9e84b1b44ed307f01cbb5eeac24e22d commit 83037ea1d9e84b1b44ed307f01cbb5eeac24e22d Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Aug 23 09:09:32 2016 -0700 X86-64: Add _dl_runtime_resolve_avx[512]_{opt|slow} [BZ #20508] There is transition penalty when SSE instructions are mixed with 256-bit AVX or 512-bit AVX512 load instructions. Since _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 save/restore 256-bit YMM/512-bit ZMM registers, there is transition penalty when SSE instructions are used with lazy binding on AVX and AVX512 processors. To avoid SSE transition penalty, if only the lower 128 bits of the first 8 vector registers are non-zero, we can preserve %xmm0 - %xmm7 registers with the zero upper bits. For AVX and AVX512 processors which support XGETBV with ECX == 1, we can use XGETBV with ECX == 1 to check if the upper 128 bits of YMM registers or the upper 256 bits of ZMM registers are zero. We can restore only the non-zero portion of vector registers with AVX/AVX512 load instructions which will zero-extend upper bits of vector registers. This patch adds _dl_runtime_resolve_sse_vex which saves and restores XMM registers with 128-bit AVX store/load instructions. It is used to preserve YMM/ZMM registers when only the lower 128 bits are non-zero. _dl_runtime_resolve_avx_opt and _dl_runtime_resolve_avx512_opt are added and used on AVX/AVX512 processors supporting XGETBV with ECX == 1 so that we store and load only the non-zero portion of vector registers. This avoids SSE transition penalty caused by _dl_runtime_resolve_avx and _dl_runtime_profile_avx512 when only the lower 128 bits of vector registers are used. _dl_runtime_resolve_avx_slow is added and used for AVX processors which don't support XGETBV with ECX == 1. Since there is no SSE transition penalty on AVX512 processors which don't support XGETBV with ECX == 1, _dl_runtime_resolve_avx512_slow isn't provided. [BZ #20495] [BZ #20508] * sysdeps/x86/cpu-features.c (init_cpu_features): For Intel processors, set Use_dl_runtime_resolve_slow and set Use_dl_runtime_resolve_opt if XGETBV suports ECX == 1. * sysdeps/x86/cpu-features.h (bit_Use_dl_runtime_resolve_opt): New. (bit_Use_dl_runtime_resolve_slow): Likewise. (index_Use_dl_runtime_resolve_opt): Likewise. (index_Use_dl_runtime_resolve_slow): Likewise. * sysdeps/x86_64/dl-machine.h (elf_machine_runtime_setup): Use _dl_runtime_resolve_avx512_opt and _dl_runtime_resolve_avx_opt if Use_dl_runtime_resolve_opt is set. Use _dl_runtime_resolve_slow if Use_dl_runtime_resolve_slow is set. * sysdeps/x86_64/dl-trampoline.S: Include <cpu-features.h>. (_dl_runtime_resolve_opt): New. Defined for AVX and AVX512. (_dl_runtime_resolve): Add one for _dl_runtime_resolve_sse_vex. * sysdeps/x86_64/dl-trampoline.h (_dl_runtime_resolve_avx_slow): New. (_dl_runtime_resolve_opt): Likewise. (_dl_runtime_profile): Define only if _dl_runtime_profile is defined. (cherry picked from commit fb0f7a6755c1bfaec38f490fbfcaa39a66ee3604) -----------------------------------------------------------------------