https://gem5-review.googlesource.com/c/public/gem5/+/5281
On Fri, Oct 27, 2017 at 1:18 PM, Gabe Black <[email protected]> wrote: > Actually, I remember implementing most if not all of SSE of some > particular vintage, so those should work just fine. I even used a test > program QEMU has to do some small amount of verification! :-) But > unfortunately I think you're right that the AVX instructions which aren't > also SSE instructions are basically unimplemented. They should be decoded > properly however, so it's probably worth looking into why this one wasn't. > > Gabe > > On Fri, Oct 27, 2017 at 1:07 PM, Sam Xi <[email protected]> wrote: > >> Ah, I see...I noticed a few commits involving decoding of VEX-prefix >> instructions and so I assumed that AVX was supported. Or is the problem >> that the decoding is supported to some degree but the actual execution >> hasn't been implemented? >> >> For what I need to do at the moment, not having good x86 SIMD support is a >> bit of a pain but not a dealbreaker. >> >> On Fri, Oct 27, 2017 at 4:02 PM Jason Lowe-Power <[email protected]> >> wrote: >> >> > Hey Sam, >> > >> > I've got some bad news... I don't think we've implemented any of the AVX >> > instructions in gem5. In fact, many of the SSE instructions are still >> > unimplemented. >> > >> > Overall, the SIMD support for x86 is pretty awful, as of the last time I >> > checked (some can correct me if things have changed significantly). It's >> > much better for ARM. I believe most, if not all, of the NEON >> instructions >> > are implemented. >> > >> > It would be great for someone to tackle the SIMD instructions on x86! In >> > fact, since the ARM SIMD instructions were implemented there is a new >> > vector register interface that we should migrate the x86 ISA to use. >> It's >> > possible that AMD has some of this code internally that's not pushed out >> > yet. Brad, Tony, care to comment? >> > >> > Sorry this isn't better news. This has been a pain point for me for a >> > while, but I haven't had any time to work on it. >> > >> > Cheers, >> > Jason >> > >> > On Fri, Oct 27, 2017 at 12:38 PM Sam Xi <[email protected]> >> wrote: >> > >> > > Hi all, >> > > >> > > I ran into a problem today involving an incorrectly decoded AVX >> > > instruction. Hoping someone can tell me of a workaround or a quick fix >> > > other than disabling AVX (unless that's the only solution). >> > > >> > > Here's a basic testcase. >> > > >> > > int main() { >> > > float x; >> > > __asm__("vxorps %0, %0, %0" : "=x"(x) : "x"(x) :); >> > > >> > > return x == 0; >> > > } >> > > >> > > Compiled with gcc 5.4: >> > > gcc -static -O3 -o test -mavx test.c >> > > >> > > Produces the following assembly: >> > > >> > > 00000000004005f0 <main>: >> > > 4005f0: 66 0f ef c9 pxor xmm1,xmm1 >> > > 4005f4: 31 c0 xor eax,eax >> > > 4005f6: 66 0f ef c0 pxor xmm0,xmm0 >> > > 4005fa: ba 00 00 00 00 mov edx,0x0 >> > > 4005ff: c5 f8 57 c0 vxorps xmm0,xmm0,xmm0 >> > > 400603: 0f 2e c1 ucomiss xmm0,xmm1 >> > > 400606: 0f 9b c0 setnp al >> > > 400609: 0f 45 c2 cmovne eax,edx >> > > 40060c: c3 ret >> > > 40060d: 0f 1f 00 nop DWORD PTR [rax] >> > > >> > > gem5 decodes the instruction as XORPS_XMM_M, instead of (something >> more >> > > like) VXORPS_XMM_XMM_XMM. This leads to a segfault in the simulated >> > program >> > > when it attempts to access an unmapped address >> > > >> > > Here is the relevant section of the debug trace. >> > > >> > > 416293000: system.cpu: Fetch >> > > 416293000: system.cpu: Translating address 0x4005f0 >> > > 416293000: system.cpu: Sending fetch for addr 0x4005f0(pa: 0x5f0) >> > > 416293000: system.cpu: -- pkt addr: 0x5f0 >> > > 416348000: system.cpu.icache_port: Received fetch response 0x5f0 >> > > 416348000: system.cpu: Complete ICache Fetch for addr 0x5f0 >> > > 416348000: global: Getting more bytes. >> > > 416348000: global: Setting origPC to 0x4005f0 >> > > 416348000: global: Found VEX two-byte prefix 0xc5. >> > > 416348000: global: Found VEX opcode 0x57. >> > > 416348000: global: Found modrm byte 0x57. >> > > 416348000: global: Collecting 1 byte displacement, got 1 bytes. >> > > 416348000: global: Collected displacement 0xffffffffffffffc9. >> > > 416348000: global: Calculating the instruction size: basePC: 0x4005f0 >> > > offset: 0x4 origPC: 0x4005f0 size: 4 >> > > 416348000: global: XORPS_XMM_M : ldfp: The address is >> 0xffffffffffffffca >> > > 416348000: system.cpu: Fault occured, scheduling fetch event >> > > panic: Tried to read unmapped address 0xffffffffffffffca. >> > > >> > > >> > > Toolchain information >> > > ===================== >> > > >> > > samxi $ gcc --version >> > > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 >> > > >> > > >> > > samxi $ as --version >> > > GNU assembler (GNU Binutils for Ubuntu) 2.26.1 >> > > >> > > gem5 revision: e79c4c6f033581f84072ddb45d2ec9543c31af55 >> > > >> > > Thanks, >> > > Sam >> > > >> > > -- >> > > Thanks, >> > > >> > > Sam Xi >> > > Harvard University >> > > Computer Science, Ph.D. Candidate >> > > http://www.samxi.org >> > > _______________________________________________ >> > > gem5-dev mailing list >> > > [email protected] >> > > http://m5sim.org/mailman/listinfo/gem5-dev >> > _______________________________________________ >> > gem5-dev mailing list >> > [email protected] >> > http://m5sim.org/mailman/listinfo/gem5-dev >> >> -- >> Thanks, >> >> Sam Xi >> Harvard University >> Computer Science, Ph.D. Candidate >> http://www.samxi.org >> _______________________________________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/gem5-dev >> > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
