[PATCH] D25692: [AVX-512] Disassembler support for rounding control and SAE attribute.

Elena Demikhovsky via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 26 02:27:22 PDT 2016

delena added inline comments.

Comment at: lib/Target/X86/X86InstrAVX512.td:1886
-                                (i32 FROUND_NO_EXC))>, EVEX_B;
+                                (i32 FROUND_NO_EXC))>, VEX_LIG, EVEX_B;
maksfb wrote:
> delena wrote:
> > I don't see LIG specification in the "sae" form of VCMP:
> > 
> > EVEX.NDS.512.66.0F.W1 C2 /r ib FV V/V AVX512F Compare packed double-precision floating-point values
> > in zmm3/m512/m64bcst and zmm2 using bits 4:0 of
> > imm8 as a comparison predicate with writemask k2
> > and leave the result in mask register k1.
> > VCMPPD k1 {k2}, zmm2,
> > zmm3/m512/m64bcst{sae}, imm8
> The spec for SAE says it "applies to scalar and 512-bit vector lengths". I don't know how CPU actually treats `L'L` when `{sae}` is set, except that  LLVM assembler generates `{0,0}`, not `{1,0}` that corresponds to 512-bit length.
> As a result if you feed assembler output to disassembler it causes disassembler to fail.
> I can speculate that LIG is implied in this case, but folks at Intel would know better. Could you check?
According to table 4-7 in the spec:
FP Instructions w/o rounding semantic:
EVEX_B - SAE control
EVEX.L’L 00, 01, 10 - for 128/256/512.

Comment at: lib/Target/X86/X86InstrAVX512.td:5817
+    defm Z : avx512_cvt_fp_rc_scalar<opc, OpcodeStr, _dst, _src,
+                               OpNodeRnd>, VEX_W, EVEX_CD8<64, CD8VT1>, XD;
maksfb wrote:
> delena wrote:
> > Why do you need to remove EVEX_V512 from the second pattern?
> Because RC implies 512-bit length ("Vector Length Orthogonality"), and putting EVEX_V512 enforces disassembler to accept `L'L={1,0}` only, while LLVM assembler generates `{0,0}` IIRC.
I read the spec again. "When EVEX is used to encode scalar instructions, L’L is generally ignored"
It means that you can put VEX_LIG to all scalars and remove EVEX_V512 from all scalar forms, right?

Comment at: utils/TableGen/X86RecognizableInstr.cpp:996
   TYPE("AVX512ICC",           TYPE_AVX512ICC)
-  TYPE("AVX512RC",            TYPE_IMM32)
+  TYPE("AVX512RC",            TYPE_IMM8)
   TYPE("brtarget32",          TYPE_RELv)
Why IMM8 ?


More information about the llvm-commits mailing list