Re: [PATCH v3 3/7] x86: re-work insn/suffix recognition

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

On Thu, Oct 6, 2022 at 9:12 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 06.10.2022 17:28, H.J. Lu wrote:
> > On Wed, Oct 5, 2022 at 11:58 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 06.10.2022 08:15, Jan Beulich via Binutils wrote:
> >>> On 06.10.2022 01:52, H.J. Lu wrote:
> >>>> Does the new assembler work on Linux kernel which has "rep movsd"?
> >>>
> >>> No. And it shouldn't, as they should never have used MOVSD. The only valid
> >>> mnemonic (in AT&T syntax) is MOVSL. If you're meaning to suggest that we
> >>> continue to support MOVSD in AT&T mode, then this will - once again for
> >>> consistency - need extending to _all_ other D-suffixable insns the SDM
> >>> specifies. I can only repeat what I've said before: Consistency is a
> >>> requirement such that users can predict assembler behavior.
> >>
> >> Note how Clang's integrated assembler doesn't even support CMPSD as a
> >> string instruction - that's imo yet more odd behavior, and likely
> >> attributed _solely_ to the goal of wanting to work around code wrongly
> >> using such.
> >
> > I think we should avoid changing assembly sources if possible.  Should we keep
> > CMPSD/MOVSD without any operands? This won't cause any confusion.
>
> Since Clang doesn't support CMPSD, I'd be (hesitantly) okay with keeping
> just the single MOVSD template having no operands. I'm still be inclined
> to warn if it ends up being used, so that people can correct their code.
> If you can explain why you think CMPSD also needs retaining in a similar
> way, I might be talked into keeping the operand-less form there as well.
> But anything going beyond that would have me fall back to requiring
> consistency throughout the mnemonics a D suffix might be used with as
> per vendor documentation.

Warning is fine with me.  We should accept MOVSD and CMPSD without
operands.


-- 
H.J.