https://bugs.kde.org/show_bug.cgi?id=521413
--- Comment #3 from Mark Wielaard <[email protected]> --- (In reply to Mark Wielaard from comment #2) > (In reply to mcermak from comment #1) > > Created attachment 194488 [details] > > possible fix for none/tests/amd64/pcmpxstrx64.c > > > > Before I start writing the x86 testcase covering this bug, I think the > > original amd64 testcase (none/tests/amd64/pcmpxstrx64.c) needs the attached > > update. Thoughts? > > Interesting, this seems to have been "wrong" since the start (2010!). > blockC starts with argL, argR 2x16bits vectors at zero and 16, read into > xxm2 and xmm12, > then comes rdx at offset 32 and rax at 40, both 8 bytes. So for those your > fix seems correct. > > What I don't fully understand is the extra memcpy for rdx at offset 40 and > with your fix > at offset 48. That one seems totally unnecessary. > > Likewise for the movupd of xmm0 and movw for rcx before the pcmpestrm call. > The result will be put into xmm0, but will not be used (as input) by the > pcmpestrm instruction. > And I don't really understand why we are interested in cx. How is that used > (either as input or output) > for the pcmpestrm instruction? O, I now see it depends on specific instruction. With pcmpXstrM output (mask) is in xmm0, with pcmpXstrI output (index) is in ecx. But I don't fully understand why we don't explicitly clear both then in that case. And why use movw cx instead of movl ecx? -- You are receiving this mail because: You are watching all bug changes.
