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

[Jan Beulich <jbeulich@suse.com>]

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.

Jan