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

[Jan Beulich]

On 19.08.2022 16:23, H.J. Lu wrote:
> On Fri, Aug 19, 2022 at 1:20 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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
> 
> In glibc, integer instructions without suffixes are used to support different
> vector sizes.

1) Could you please point me at an example?

2) How is this related? We wouldn't require suffixes all of the sudden,
we'd only permit their use.

Jan