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

[Elena Demikhovsky via llvm-commits]

delena added inline comments.


================
Comment at: lib/Target/X86/X86InstrAVX512.td:1886
                                     imm:$cc,
-                                (i32 FROUND_NO_EXC))>, EVEX_B;
+                                (i32 FROUND_NO_EXC))>, VEX_LIG, EVEX_B;
 
----------------
maksfb wrote:
> delena wrote:
> > 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.
> > 
> Does it make the spec wrong? Is there any non-512-bit vector instruction with SAE?
1) You actually changed instruction encoding. We have a lot of encoding tests. Do you want to say that our tests do not cover these cases?
2) Could you, please, check what encoding is generated by GCC?
3) In order to be sure that the HW ignores L'L you can check with XED or SDE. XED is a part of SDE package which is free on Intel site.


================
Comment at: utils/TableGen/X86RecognizableInstr.cpp:996
   TYPE("AVX512ICC",           TYPE_AVX512ICC)
-  TYPE("AVX512RC",            TYPE_IMM32)
+  TYPE("AVX512RC",            TYPE_IMM8)
   TYPE("brtarget32",          TYPE_RELv)
----------------
maksfb wrote:
> delena wrote:
> > Why IMM8 ?
> Made more sense than IMM32 since it saves some bytes.
Where?


https://reviews.llvm.org/D25692