Re: [PATCH 02/12] x86: correct VCVT{,U}SI2SD rounding mode handling

[Jan Beulich <jbeulich@suse.com>]

On 21.07.2021 12:19, Jan Beulich via Binutils wrote:
> With EVEX.W clear the instruction doesn't ignore the rounding mode, but
> (like for other insns without rounding semantics) EVEX.b set causes #UD.
> Hence the handling of EVEX.W needs to be done when processing
> evex_rounding_64_mode, not at the decode stages.
> 
> Derive a new 64-bit testcase from the 32-bit one to cover the different
> EVEX.W treatment in both cases.

I've committed this and the other parts of this series, but I wonder ...

> ---
> This demonstrates a broader problem: Instructions not permitting
> rounding control at all (which #UD if such was specified in the
> encoding) get displayed without any hint to the badness, merely by there
> not being any respective operand at all. While OP_E_memory() handles
> EVEX.b (broadcast) wrongly being set (in an unhelpful way, in that not
> all of the opcode bytes get consumed), there's nowhere that EVEX.b
> (rounding) would be checked except for the three EXxEVexR, EXxEVexR64,
> and EXxEVexS ones.

... whether you have an opinion here. We could follow the model of
marking decoded bits used, but I'd like to avoid calling BadOp() from
the top level handler (I'd really like to get many of its uses dropped,
as it screws up disassembly of subsequent insns). Hence my preference
would be to express this as a pseudo-operand, e.g. {rn-bad} (to
parallel {rn-sae} and thus making visible what the two L'L bits are
set to in the encoding).

Jan