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

Jan Beulich jbeulich@suse.com
Thu Aug 18 06:07:57 GMT 2022

On 17.08.2022 21:19, H.J. Lu wrote:
> On Tue, Aug 16, 2022 at 12:30 AM Jan Beulich <jbeulich@suse.com> 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.)
>> As a side effect of folding the VCVT{,T}S{S,D,H}2SI templates,
>> VCVT{,T}SH2SI will now allow L and Q suffixes, consistent with
>> VCVT{,T}S{S,D}2SI. All of these remain inconsistent with their 2USI
>> counterparts (which I think should also be corrected, but perhaps better
>> in a separate change).
> I don't think allowing more unnecessary L and Q suffixes for AVX
> instructions is desirable.   I prefer not to allow unnecessary L and
> Q suffixes in folded entries.   We can add special entries to allow
> the existing instructions with suffixes.

I think we've been there before, and I continue to think that we should
be consistent throughout the entire ISA in allowing suffixes when GPRs
or their equivalent memory operands are involved. That's in the spirit
of the original AT&T syntax intentions, after all. I have to admit that
I find it particularly worrying that you suggest to introduce new
templates, when the overall / long term goal is to reduce the set, to
keep it manageable in spite of all the new additions that yer yet to

As pointed out elsewhere, any inconsistencies here make it harder for
people to write e.g. heavily macro-ized code. Similarly it can result
in surprises when cloning existing code to deal with new extensions.


More information about the Binutils mailing list