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

[H.J. Lu]

On Thu, Jul 22, 2021 at 4:18 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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).

{rn-bad} sounds good to me.

Thanks.

-- 
H.J.