|
From: Ólafur W. <ol...@gm...> - 2012-03-13 18:29:55
|
Hey, I am sort of new with valgrind so please forgive any silly oversights. I am running a codebase through valgrind to check for cache misses. I is the first time it has been ran through valgrind. The code is basic vector / list / char* stuff (nothing too fancy) but one part uses SSE for manhattan distance calculation. I get this error on that function. vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x16 ==18426== at 0x804BE18: manhattan(unsigned char const*, unsigned char const*) (emmintrin.h:208) I searched around for this and found someone talking about very similar instruction bytes and a bug fix for valgrind back in 2011. I saw that I was under an old version. I update it but I still have the same error. How might I go around fixing this? Cheers, Ólafur Waage |
|
From: John R. <jr...@bi...> - 2012-03-13 19:39:05
|
> vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x16 > ==18426== at 0x804BE18: manhattan(unsigned char const*, unsigned char const*) (emmintrin.h:208) That's "PEXTRD r/m32, xmm2, Ib" which extracts a 32-bit wide, 32-bit aligned, known-in-advance slice from xmm2, then places the slice into a general register or memory location. The opcode is from the SSE4.1 extensions, and occupies four bytes; the valgrind report omits the operands. The easiest way to deal with this is to ask the compiler not to use SSE4.1. (In this case the compiler probably would store the 128-bit xmm2 into memory, then fetch the selected 32-bit slice.) Otherwise, it's somewhat tedious work inside valgrind's VEX x86->IR translator. -- |
|
From: John R. <jr...@bi...> - 2012-03-13 19:47:49
|
>> vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x16
> That's "PEXTRD r/m32, xmm2, Ib" ...
Perhaps just copy the relevant lines
from VEX/priv/guest_amd64_toIR.c
to VEX/priv/guest_x86_toIR.c
--
|
|
From: Ólafur W. <ol...@gm...> - 2012-03-13 20:49:10
|
On Tue, Mar 13, 2012 at 7:39 PM, John Reiser <jr...@bi...> wrote: > > vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0x16 > > ==18426== at 0x804BE18: manhattan(unsigned char const*, unsigned char > const*) (emmintrin.h:208) > > That's "PEXTRD r/m32, xmm2, Ib" which extracts a 32-bit wide, 32-bit > aligned, > known-in-advance slice from xmm2, then places the slice into a general > register > or memory location. The opcode is from the SSE4.1 extensions, and occupies > four bytes; the valgrind report omits the operands. > > The easiest way to deal with this is to ask the compiler not to use SSE4.1. > (In this case the compiler probably would store the 128-bit xmm2 into > memory, > then fetch the selected 32-bit slice.) > Otherwise, it's somewhat tedious work inside valgrind's VEX x86->IR > translator. Removing SSE4.1 and SSE4.2 flags did the trick. Thanks. |
|
From: Julian S. <js...@ac...> - 2012-03-15 07:33:10
|
On Tuesday, March 13, 2012, Ólafur Waage wrote: > Removing SSE4.1 and SSE4.2 flags did the trick. Thanks. SSE4.x isn't supported in 32-bit mode, but it is in 64 bit mode. So, if you need it, rebuild your program as a 64 bit app, and try again. J |