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

Reply via email to