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

Jan Beulich jbeulich@suse.com
Fri Aug 19 08:19:56 GMT 2022


On 18.08.2022 16:46, H.J. Lu wrote:
> On Wed, Aug 17, 2022 at 11:08 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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
>> come.
>>
>> 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.
>>
> 
> Will it work without unnecessary suffixes?

I'm afraid I can only guess at what "it" means in your reply. Of course
things will work for people who have never used what you call
"unnecessary" prefixes. But there are other people who believe that the
spirit of AT&T syntax is to put suffixes everywhere where multiple
operand sizes are possible, and where the suffix allows to distinguish
them. One possible reason for that could be to have the re-assurance of
the assembler pointing out mismatches between suffix and operand(s).

Jan


More information about the Binutils mailing list