[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 --- Comment #19 from Mark Wielaard --- Created attachment 100956 --> https://bugs.kde.org/attachment.cgi?id=100956&action=edit Current stdout.diff file for new fma4.vgtest and proposed patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 --- Comment #18 from Mark Wielaard --- Created attachment 100955 --> https://bugs.kde.org/attachment.cgi?id=100955&action=edit Testcases for fma4 instructions Here are some testcases for the FMA4 instructions. I haven't looked yet at the XOP instructions. Maybe it is an idea to do FMA4 and XOP as separate patches? The testcase is based on the idea from the avx-1.c testcase. It creates a a block of values loads some of the values into xmm/ymm registers and creates a memory reference to another. Then it prints the contents of the block before and after the various instructions. The expected output comes from running the program on an actual processor having fma4 instructions. This is then compared with the same program running under valgrind. With the current patch there are some differences. First the 256bit ymm operations aren't supported, so they have been disabled in the testcase for now. But I am not sure we really should enable the fma4 cpuid bit in valgrind before we really support them. Secondly some 128bit xmm operations should clear the upper 128 bits of the corresponding YMM register to zeros and don't do so at the moment. Lastly the "full 0xFF" testcases do show some differences (but the zeros, ones and random cases all look fine). I'll also attach the stdout.diff next. If you think doing full bit-indentical tests are not fair/achievable for these instructions then let me know and we can see if we can create some testcases that explicitly work on float/double results. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Mark Wielaard changed: What|Removed |Added CC||m...@redhat.com --- Comment #17 from Mark Wielaard --- About the testcase. The __builtin_ia32_xxx are really just internal compiler details. They might or might not be there between versions of the same compiler or between different compilers. They might not even implement the same thing or take different arguments. For example the testcase uses __builtin_ia32_vpcomew with an extra argument that says which kind of operation/memonic is really meant, while gcc provides 8 separate __builtin_ia32_vpcom[xxx] to provide the same functionality. The testcase uses separate __builtin_ia32_vfnmaddxx and __builtin_ia32_vfnmsubxx functions, while gcc just provides one which takes a positive or negative argument. There is also no guarantee that these functions translate to some exact instruction (sequence). So it would be better to rewrite the testcase to use explicit inline assembly using the exact instructions that we want to test. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Stefano Bonicatti changed: What|Removed |Added CC||smj...@gmail.com --- Comment #16 from Stefano Bonicatti --- I have tested with the test case attached in this bug report and i can confirm the issue. I can also confirm that running the same test case with the patch works, valgrind doesn't crash/complains about illegal instructions. Tested with an AMD FX 6300. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 p4pl...@gmail.com changed: What|Removed |Added Attachment #89121|0 |1 is obsolete|| --- Comment #15 from p4pl...@gmail.com --- Created attachment 100633 --> https://bugs.kde.org/attachment.cgi?id=100633&action=edit XOP/FMA with CPUID support I had a bit of time this week, (a brisk two years later...) and took the time to rebase to the latest svn copy of valgrind. In addition to updating, I added the missing CPUID support. Users running FX-8150-like processors will now be detected as such. Is there anything else needed before this patch can be merged? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Beau V.C. Bellamy changed: What|Removed |Added CC||bellamy.b...@gmail.com --- Comment #14 from Beau V.C. Bellamy --- Any progress on this? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 --- Comment #13 from dra...@shaw.ca --- This bug is getting critical for me. I took the patch and applied it to the valgrind trunk. It applied cleanly. Once I ran the new valgrind, there were many more instructions that were processed. I got to a point where it ran into a new instruction that this patch does not cover. The error for the new instruction is: vex amd64->IR: unhandled instruction bytes: 0x8F 0x68 0x20 0x95 0xE4 0xC0 0x8F 0xC8 vex amd64->IR: REX=0 REX.W=0 REX.R=1 REX.X=0 REX.B=0 vex amd64->IR: VEX=1 VEX.L=0 VEX.n=0xB ESC=??? vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==21476== valgrind: Unrecognised instruction at address 0x65cff64. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Andreas Boerner changed: What|Removed |Added CC||andreas.boer...@w84u.org -- You are receiving this mail because: You are watching all bug changes.
