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

Jan Beulich jbeulich@suse.com
Mon Aug 22 09:34:26 GMT 2022


On 19.08.2022 19:00, H.J. Lu wrote:
> On Fri, Aug 19, 2022 at 7:49 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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.
> 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strlen-evex-base.S

I'm afraid I don't see how this is related to the topic. Yes, that's one
way to do such programming. But it doesn't mean others shouldn't be
allowed to do things differently, to their liking. Plus - integer
instructions aren't relevant here at all; we permit suffixes for all of
them anyway. Vector / scalar instructions are what matters, and I see
they actually abstract kmov{q,d} via a KMOV pre-processor macro, for
example. (Not relevant here: I actually view it as a shortcoming of
the assembler that they need to do that, rather than us allowing use of
"kmov" without the Intel-mandated suffix. Obviously this would extend
to other insns as well.)

>> 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.
> 
> We shouldn't add suffixes when they aren't needed.   Suffixes aren't
> required.

You're re-stating what I've said. What you look to not be willing to
accept is that we ought to _allow_ use of suffixes in _all_ places
where they might matter, _irrespective_ of them being required.

Jan


More information about the Binutils mailing list