Ping: [PATCH v2 1/7] x86/Intel: restrict suffix derivation

[Jan Beulich <jbeulich@suse.com>]

On 26.08.2022 12:30, Jan Beulich via Binutils wrote:
> While in some cases deriving an AT&T-style suffix from an Intel syntax
> memory operand size specifier is necessary, in many cases this is not
> only pointless, but has led to the introduction of various workarounds:
> Excessive use of IgnoreSize and NoRex64 as well as the ToDword and
> ToQword attributes. Suppress suffix derivation when we can clearly tell
> that the memory operand's size isn't going to be needed to infer the
> possible need for the low byte/word opcode bit or an operand size prefix
> (0x66 or REX.W).
> 
> As a result ToDword and ToQword can be dropped entirely, plus a fair
> number of IgnoreSize and NoRex64 can also be got rid of. Note that
> IgnoreSize needs to remain on legacy encoded SIMD insns with GPR
> operand, to avoid emitting an operand size prefix in 16-bit mode. (Since
> 16-bit code using SIMD insns isn't well tested, clone an existing
> testcase just enough to cover a few insns which are potentially
> problematic but are being touched here.)
> 
> Note that while folding the VCVT{,T}S{S,D}2SI templates, VCVT{,T}SH2SI
> isn't included there. This is to fulfill the request of not allowing L
> and Q suffixes there, despite the inconsistency with VCVT{,T}S{S,D}2SI.
> ---
> Long term suffix derivation should be dropped altogether, not the least
> such that bogus error messages like "incorrect register `...' used with
> `...' suffix" don't misguid people anymore when no suffix was used at
> all.
> ---
> v2: Don't cover VCVT{,T}SH2SI with the templatization.

Since you didn't like the respective aspect of v1, may I ask for explicit
feedback on v2? If I don't hear back by the end of next week, I guess I'll
commit this change.

Jan