[PATCH v2] x86: Ignore rounding for vcvt[,u]si2sd under r32 and vcvt[,u]dq2pd instead of reporting bad

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, January 16, 2025 4:34 PM
> 
> On 16.01.2025 03:44, Haochen Jiang wrote:
> > Note: It seems to me that omitting 512 when using .insn with
> > vcvt[,u]dq2pd will lead to 256 size. That is why I am not omitting
> > them. It might be a bug for .insn but I did not look into that.
>

I found that I mistyped the size. It should be omitting 256 leading to
512. In case someone else did not get the real issue here.
 
> That's due to logic in s_insn() which wasn't updated for AVX10.2, yet:
> 
> 	  if (!i.tm.opcode_modifier.evex)
> 	    {
> 	      /* Do _not_ consider AVX512VL here.  */
> 	      if (i.rounding.type != rc_none || combined.bitfield.zmmword)
> 	        i.tm.opcode_modifier.evex = EVEX512;
> 	      else if (combined.bitfield.ymmword)
> 	        i.tm.opcode_modifier.evex = EVEX256;
> 	      else if (combined.bitfield.xmmword)
> 	        i.tm.opcode_modifier.evex = EVEX128;
> 	    }
> 
> Considering the AVX512VL related comment, I'm not entirely certain yet what
> to best do here.

The AVX512VL related comment seems to be a comment that: 
a) If AVX512VL is not enabled, we could still process operands so that we will not
check AVX512VL.
or
b) Scalar insts are using just xmm while EVEX128 also only using xmm, we have no
way to distinguish them while scalar does not need AVX512VL so that we will not
check AVX512VL.

I am not sure whether or which is the correct meaning. But the b) might be the
answer.

But I suppose " i.rounding.type != rc_none" might could be removed. I removed
that and saw no test fail. Let me think twice if I can get a testcase crash the .insn
after removing that. (And the texi file need to be revised if removed.)

Thx,
Haochen