[PATCH] D35785: [AsmParser][AVX512]Enhance OpMask/Zero/Merge syntax check rubostness

[coby via Phabricator via llvm-commits]

coby added inline comments.


================
Comment at: test/MC/X86/avx512-err.s:8
+// ERR: Expected a {z} mark at this point
+vfmsub213ps %zmm8, %zmm8, %zmm8{%k2} {rn-sae}
+
----------------
m_zuckerman wrote:
> m_zuckerman wrote:
> > So why this is an error? you mustn't have the {z} mask before the {rn-sae}. 
> > Again according to the ISA section 2.5.4 
> > https://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdf
> > for example: 
> > vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}
> > 
> you don't must the {z} before the {rn-sae}
Examine the example you took out of the Spec:
"vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}" (Intel style)
The rounding mark is stated as a distinctive operand of the instruction (note the comma).
As said above - only OpMask/Zero  marks can **immediately** follow a destination
**immediately** ::= As a mark stating properties of the followed operand (or, if you want, not as a distinctive operand)


================
Comment at: test/MC/X86/avx512-err.s:10
+
+// ERR: Expected an op-mask register at this point
+vfmsub213ps %zmm8, %zmm8, %zmm8 {rn-sae}
----------------
m_zuckerman wrote:
> coby wrote:
> > m_zuckerman wrote:
> > > why is this error a true? 
> > > according to the ISA, the instruction can optionally have op mask.  
> > The error due to the misplacing of the rounding (rn-sae) mark (line 11).
> > Only an OpMask / Zero mark is allowed to immediately follow a destination operand.
> can you add also the intel syntax test since it is written in a different way? The location of the mask is the first and not the last.
> 
> For example: 
> vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}
> 
> and see that you are getting the same error when you insert 
> vaddps zmm7 , zmm2, zmm4, {rd-sae}
> 
The code flow dictates that this added check will occur after any operand of an AVX512 instruction (more precisely - if this operand is followed by an alleged curly braces marks), so it catches both mischief conducted on Intel and GNU. In other words - it matters not whether the faulty occurs on the last/first operand 


Repository:
  rL LLVM

https://reviews.llvm.org/D35785