Weird behaviour with KNC and AVX(512)

[a0rland0]

Hi. I downloaded the latest version of XED and found some weird behaviors when compiling and running "xed.exe". I checked the previous messages that were reported and some issues that I'll describe next might have been reported already but I decided to mention them anyway.

1) when generating xed with "--knc" several instructions just "disappear". It's easy to see this when comparing the size of both files:

5687296 xed.exe (without knc) 2791424 xedknc.exe (with knc)

For example if I disassemble any AVX512 instruction the result is an error message

2) when disassembling some knc instructions the VSIB byte seems to be the "same" as MODRM; for example: "xedknc -16 -d 62f2790890 40 01"

3) shouldn't the result of "xed -16 -d 67 c4 e2 d5 90 1c 2d f9 ff ff 9f" be something like this "vpgatherdd ymm3, dword ptr [ymm5 - 0x60000007], ymm5"?

I'm catching all these errors because I generated a huge data file with all instructions that are declared in xed "datafiles" (i.e. all possibilities in mode 16-bit/32-bit/64-bit).

Thank you

[flobernd]

1. That is correct, as XED can either be compiled with KNC support or with AVX512. These options are mutally exclusive
2. This instruction seems to be invalid
3. This instruction is invalid as well (gather register constraints are violated)

[a0rland0]

Thank you for your answer.

Maybe I'm reading the patterns in the wrong way, but for case 2) we have

xedknc -16 -d 62 f2 79 08 90 40 01

which results in

62F27908904001 ICLASS: VPGATHERDD CATEGORY: KNC EXTENSION: KNCE IFORM: VPGATHERDD_ZMMzd_MASK1mskw_MEMzv ISA_SET: KNCE SHORT: vpgatherdd zmm0, k0, dword ptr [ax+zmm0*1+0x4]

if I break down all bytes I get this (according to Intel ® Xeon Phi ™ Coprocessor Instruction Set Architecture Reference Manual, 327364-001)

62  byte 0
f2  byte 1: R|X|B|R'|mmmm = 1|1|1|1 |0010
79  byte 2: W|vvvv|0|pp = 0|1111|0|01
08  byte 3: E|SSS|V'|kkk = 0|000|1 |000
90  opcode
40  modrm/sib???
01  offset; note that UPCONVERT_INT32_LOAD will give a multiplication factor of 4

if I look at the pattern for "VPGATHERDD" (in "datafiles\knc\lrb2-evex-isa.txt")

ICLASS : VPGATHERDD ATTRIBUTES : KNC_GATHER KNC_I32 gather REQUIRES_ALIGNMENT SPECIAL_AGEN_REQUIRED MASKOP_EVEX PATTERN : KVV 0x90 V66 V0F38 W0 NO_SPARSE_EVSR MOD[mm] MOD!=3 REG[rrr] RM[0b100] KNC_VMODRM() UPCONVERT_INT32_LOAD() OPERANDS : REG0=ZMM_R3():rw:zd REG1=MASK1():rw:mskw MEM0:r:zv:TXT=NT:TXT=CONVERT NELEM=1:SUPP

the first think that is wrong in my opinion is the "RM[0b100]" constraint. If "40" is modrm then clearly RM is 0 and not 4 (mod = 1, reg = 0, rm = 0). If I expand "KNC_VMODRM()" then it seems obvious that VSIB is mandatory (regardless of the value of rm)

KNC_VMODRM():: MOD=0b00 KNC_VSIB() | MOD=0b01 KNC_VSIB() MEMDISP8() | MOD=0b10 KNC_VSIB() MEMDISP32() |

note that value 40 (mod=1) forces an 8-bit displacement. What is weird is that VSIB is completelly absent and thats why I said that modrm/vsib seem to be the same byte (weird).

For case 3) I know that xed fails with error

67C4E2D5901C2DF9FFFF9F ERROR: GATHER_REGS Could not decode at offset: 0x0 PC: 0x0: [67C4E2D5901C2DF9FFFF9F00000000]

but looking at the pattern it seems to be a valid instruction.

[flobernd]

VSIB is not valid in 16-bit mode at all, if I remember correctly. That might be the problem here. I reported a related issue (https://github.com/intelxed/xed/issues/80) some time ago, but the quick and dirty fix did the trick for me, so not sure if there is still a problem or if it's just because of the VSIB+16bit combination.