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

["H.J. Lu" <hjl.tools@gmail.com>]

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.

> them. One possible reason for that could be to have the re-assurance of
> the assembler pointing out mismatches between suffix and operand(s).



-- 
H.J.