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

Maksim Panchenko via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 26 22:28:28 PDT 2016


maksfb added a comment.

I think the focus should be on fixing the state of LLVM's disassembler for AVX-512. While there could be issues with the encoder too, and it's important to find out if indeed the encoder has to be fixed, that has to be handled separately. This diff fixes multiple failures of LLVM disassembler while handling binaries with AVX-512, but it does not fix them all.

Since you have encoding tests - you can pass the output of assembler to disassembler. It's one line in .test file(s).



================
Comment at: lib/Target/X86/X86InstrAVX512.td:1886
                                     imm:$cc,
-                                (i32 FROUND_NO_EXC))>, EVEX_B;
+                                (i32 FROUND_NO_EXC))>, VEX_LIG, EVEX_B;
 
----------------
delena wrote:
> 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.
1. How? If you think I've changed the encoding could you provide an example? Do you have a test case that checks SAE encoding? What does it expect L'L to be? I'm based on rev from Oct 11th and all tests pass.
2. `as` from binutils 2.26.1 generates `{0,0}`.
3. I agree, it's important to make sure LLVM codegen for Intel's extension is not broken.



https://reviews.llvm.org/D25692





More information about the llvm-commits mailing list