[PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[Jan Beulich]

These are regular SSE/SSE2 insns, and hence should be accepted
irrespective of MMX as a feature being enabled. Since the MMX CPU
feature is intentionally not implicitly enabled by ".arch .sse", MMX
registers may be left unrecognized only when both MMX and SSE are
disabled. The errors previously generated on most of these insns in this
mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
mm<N> source operands would silently have been taken as memory operands
of those names, i.e. wrong code was silently generated.

gas/
2020-02-XX  Jan Beulich  <jbeulich@suse.com>

	* config/tc-i386.c (parse_real_register): Accept MMX registers
	also when SSE is enabled.
	* testsuite/gas/i386/nommx-4.s, testsuite/gas/i386/nommx-4.l:
	New.
	* testsuite/gas/i386/i386.exp: Run new test.

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -11877,7 +11877,9 @@ parse_real_register (char *reg_string, c
       && !cpu_arch_flags.bitfield.cpui386)
     return (const reg_entry *) NULL;
 
-  if (r->reg_type.bitfield.class == RegMMX && !cpu_arch_flags.bitfield.cpummx)
+  if (r->reg_type.bitfield.class == RegMMX
+      && !cpu_arch_flags.bitfield.cpusse
+      && !cpu_arch_flags.bitfield.cpummx)
     return (const reg_entry *) NULL;
 
   if (!cpu_arch_flags.bitfield.cpuavx512f)
--- a/gas/testsuite/gas/i386/i386.exp
+++ b/gas/testsuite/gas/i386/i386.exp
@@ -191,6 +191,7 @@ if [expr ([istarget "i*86-*-*"] ||  [ist
     run_list_test "nommx-1" "-al"
     run_list_test "nommx-2" "-march=core+nommx -al"
     run_list_test "nommx-3" "-march=+nommx -al"
+    run_list_test "nommx-4" "-al"
     run_list_test "nosse-1" "-al"
     run_list_test "nosse-2" "-march=core+nosse -al"
     run_list_test "nosse-3" "-march=+nosse -al"
--- /dev/null
+++ b/gas/testsuite/gas/i386/nommx-4.l
@@ -0,0 +1,56 @@
+.*: Assembler messages:
+.*:23: Error: .*\.nosse.*
+.*:24: Error: .*\.nosse.*
+.*:25: Error: .*\.nosse.*
+.*:26: Error: .*\.nosse.*
+.*:27: Error: .*\.nosse.*
+.*:28: Error: .*\.nosse.*
+.*:29: Error: .*\.nosse.*
+.*:30: Error: .*\.nosse.*
+GAS LISTING .*
+#...
+[ 	]*[1-9][0-9]*[ 	]+\#.*
+[ 	]*[1-9][0-9]*[ 	]+\.text
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2DC0[ 	]+cvtpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2AC0[ 	]+cvtpi2pd %mm0, %xmm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2AC0[ 	]+cvtpi2ps %mm0, %xmm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2DC0[ 	]+cvtps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2CC0[ 	]+cvttpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2CC0[ 	]+cvttps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? F20FD6C0[ 	]+movdq2q	%xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? F30FD6C0[ 	]+movq2dq	%mm0, %xmm0
+[ 	]*[1-9][0-9]*[ 	]*
+[ 	]*[1-9][0-9]*[ 	]+\.arch .nommx
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2DC0[ 	]+cvtpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2AC0[ 	]+cvtpi2pd %mm0, %xmm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2AC0[ 	]+cvtpi2ps %mm0, %xmm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2DC0[ 	]+cvtps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2CC0[ 	]+cvttpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2CC0[ 	]+cvttps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? F20FD6C0[ 	]+movdq2q	%xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? F30FD6C0[ 	]+movq2dq	%mm0, %xmm0
+[ 	]*[1-9][0-9]*[ 	]*
+[ 	]*[1-9][0-9]*[ 	]+\.arch \.nosse
+[ 	]*[1-9][0-9]*[ 	]+cvtpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]*[ 	]+cvtpi2pd %mm0, %xmm0
+[ 	]*[1-9][0-9]*[ 	]+cvtpi2ps %mm0, %xmm0
+[ 	]*[1-9][0-9]*[ 	]+cvtps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]*[ 	]+cvttpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]*[ 	]+cvttps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]*[ 	]+movdq2q	%xmm0, %mm0
+[ 	]*[1-9][0-9]*[ 	]+movq2dq	%mm0, %xmm0
+[ 	]*[1-9][0-9]*[ 	]*
+[ 	]*[1-9][0-9]*[ 	]+\.arch generic32
+[ 	]*[1-9][0-9]*[ 	]+\.arch \.sse
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2AC0[ 	]+cvtpi2ps %mm0, %xmm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2DC0[ 	]+cvtps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 0F2CC0[ 	]+cvttps2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]*[ 	]*
+[ 	]*[1-9][0-9]*[ 	]+\.arch \.sse2
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2DC0[ 	]+cvtpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2AC0[ 	]+cvtpi2pd %mm0, %xmm0
+[ 	]*[1-9][0-9]* \?\?\?\? 660F2CC0[ 	]+cvttpd2pi %xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? F20FD6C0[ 	]+movdq2q	%xmm0, %mm0
+[ 	]*[1-9][0-9]* \?\?\?\? F30FD6C0[ 	]+movq2dq	%mm0, %xmm0
+[ 	]*[1-9][0-9]*[ 	]*
+#pass
--- /dev/null
+++ b/gas/testsuite/gas/i386/nommx-4.s
@@ -0,0 +1,45 @@
+# Test .arch .nommx with .sse/.sse2
+	.text
+	cvtpd2pi %xmm0, %mm0
+	cvtpi2pd %mm0, %xmm0
+	cvtpi2ps %mm0, %xmm0
+	cvtps2pi %xmm0, %mm0
+	cvttpd2pi %xmm0, %mm0
+	cvttps2pi %xmm0, %mm0
+	movdq2q	%xmm0, %mm0
+	movq2dq	%mm0, %xmm0
+
+	.arch .nommx
+	cvtpd2pi %xmm0, %mm0
+	cvtpi2pd %mm0, %xmm0
+	cvtpi2ps %mm0, %xmm0
+	cvtps2pi %xmm0, %mm0
+	cvttpd2pi %xmm0, %mm0
+	cvttps2pi %xmm0, %mm0
+	movdq2q	%xmm0, %mm0
+	movq2dq	%mm0, %xmm0
+
+	.arch .nosse
+	cvtpd2pi %xmm0, %mm0
+	cvtpi2pd %mm0, %xmm0
+	cvtpi2ps %mm0, %xmm0
+	cvtps2pi %xmm0, %mm0
+	cvttpd2pi %xmm0, %mm0
+	cvttps2pi %xmm0, %mm0
+	movdq2q	%xmm0, %mm0
+	movq2dq	%mm0, %xmm0
+
+	.arch generic32
+	.arch .sse
+	cvtpi2ps %mm0, %xmm0
+	cvtps2pi %xmm0, %mm0
+	cvttps2pi %xmm0, %mm0
+
+	.arch .sse2
+	cvtpd2pi %xmm0, %mm0
+	cvtpi2pd %mm0, %xmm0
+	cvttpd2pi %xmm0, %mm0
+	movdq2q	%xmm0, %mm0
+	movq2dq	%mm0, %xmm0
+
+	.p2align 4

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[H.J. Lu]

On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> These are regular SSE/SSE2 insns, and hence should be accepted
> irrespective of MMX as a feature being enabled. Since the MMX CPU
> feature is intentionally not implicitly enabled by ".arch .sse", MMX

This begs the question if ".arch .sse" should enable MMX.

> registers may be left unrecognized only when both MMX and SSE are
> disabled. The errors previously generated on most of these insns in this
> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
> mm<N> source operands would silently have been taken as memory operands
> of those names, i.e. wrong code was silently generated.

This is the real problem.  What happens if YMM/ZMM are used with
AVX disabled?

> gas/
> 2020-02-XX  Jan Beulich  <jbeulich@suse.com>
>
>         * config/tc-i386.c (parse_real_register): Accept MMX registers
>         also when SSE is enabled.
>         * testsuite/gas/i386/nommx-4.s, testsuite/gas/i386/nommx-4.l:
>         New.
>         * testsuite/gas/i386/i386.exp: Run new test.
>


-- 
H.J.

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[Jan Beulich]

On 13.02.2020 12:43, H.J. Lu wrote:
> On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> These are regular SSE/SSE2 insns, and hence should be accepted
>> irrespective of MMX as a feature being enabled. Since the MMX CPU
>> feature is intentionally not implicitly enabled by ".arch .sse", MMX
> 
> This begs the question if ".arch .sse" should enable MMX.

Well, I understood not doing so was intentional, for allowing
people to write SSE code which is free of MMX insns.

>> registers may be left unrecognized only when both MMX and SSE are
>> disabled. The errors previously generated on most of these insns in this
>> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
>> mm<N> source operands would silently have been taken as memory operands
>> of those names, i.e. wrong code was silently generated.
> 
> This is the real problem.  What happens if YMM/ZMM are used with
> AVX disabled?

I don't understand. When AVX is disabled, ymm<N> are expected to
be ordinary identifiers. Same for AVX512F and zmm<N> as well as
k<N>. When MMX is disabled the situation is different, due to
those SSE insns which access MMX registers.

Jan

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[H.J. Lu]

On Thu, Feb 13, 2020 at 5:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.02.2020 12:43, H.J. Lu wrote:
> > On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> These are regular SSE/SSE2 insns, and hence should be accepted
> >> irrespective of MMX as a feature being enabled. Since the MMX CPU
> >> feature is intentionally not implicitly enabled by ".arch .sse", MMX
> >
> > This begs the question if ".arch .sse" should enable MMX.
>
> Well, I understood not doing so was intentional, for allowing
> people to write SSE code which is free of MMX insns.

True.

> >> registers may be left unrecognized only when both MMX and SSE are
> >> disabled. The errors previously generated on most of these insns in this
> >> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
> >> mm<N> source operands would silently have been taken as memory operands
> >> of those names, i.e. wrong code was silently generated.
> >
> > This is the real problem.  What happens if YMM/ZMM are used with
> > AVX disabled?
>
> I don't understand. When AVX is disabled, ymm<N> are expected to
> be ordinary identifiers. Same for AVX512F and zmm<N> as well as
> k<N>. When MMX is disabled the situation is different, due to
> those SSE insns which access MMX registers.
>

I think we should disallow naked MMX register in SSE instructions
if cpummx is 0.

-- 
H.J.

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[Jan Beulich]

On 13.02.2020 15:15, H.J. Lu wrote:
> On Thu, Feb 13, 2020 at 5:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 13.02.2020 12:43, H.J. Lu wrote:
>>> On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> These are regular SSE/SSE2 insns, and hence should be accepted
>>>> irrespective of MMX as a feature being enabled. Since the MMX CPU
>>>> feature is intentionally not implicitly enabled by ".arch .sse", MMX
>>>
>>> This begs the question if ".arch .sse" should enable MMX.
>>
>> Well, I understood not doing so was intentional, for allowing
>> people to write SSE code which is free of MMX insns.
> 
> True.
> 
>>>> registers may be left unrecognized only when both MMX and SSE are
>>>> disabled. The errors previously generated on most of these insns in this
>>>> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
>>>> mm<N> source operands would silently have been taken as memory operands
>>>> of those names, i.e. wrong code was silently generated.
>>>
>>> This is the real problem.  What happens if YMM/ZMM are used with
>>> AVX disabled?
>>
>> I don't understand. When AVX is disabled, ymm<N> are expected to
>> be ordinary identifiers. Same for AVX512F and zmm<N> as well as
>> k<N>. When MMX is disabled the situation is different, due to
>> those SSE insns which access MMX registers.
> 
> I think we should disallow naked MMX register in SSE instructions
> if cpummx is 0.

This is not going to be acceptable in Intel syntax mode. Having to
use % prefixes there makes no sense at all, unless explicitly
asking for it by ".intel_syntax prefix".

Jan

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[H.J. Lu]

On Thu, Feb 13, 2020 at 6:50 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.02.2020 15:15, H.J. Lu wrote:
> > On Thu, Feb 13, 2020 at 5:39 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 13.02.2020 12:43, H.J. Lu wrote:
> >>> On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> These are regular SSE/SSE2 insns, and hence should be accepted
> >>>> irrespective of MMX as a feature being enabled. Since the MMX CPU
> >>>> feature is intentionally not implicitly enabled by ".arch .sse", MMX
> >>>
> >>> This begs the question if ".arch .sse" should enable MMX.
> >>
> >> Well, I understood not doing so was intentional, for allowing
> >> people to write SSE code which is free of MMX insns.
> >
> > True.
> >
> >>>> registers may be left unrecognized only when both MMX and SSE are
> >>>> disabled. The errors previously generated on most of these insns in this
> >>>> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
> >>>> mm<N> source operands would silently have been taken as memory operands
> >>>> of those names, i.e. wrong code was silently generated.
> >>>
> >>> This is the real problem.  What happens if YMM/ZMM are used with
> >>> AVX disabled?
> >>
> >> I don't understand. When AVX is disabled, ymm<N> are expected to
> >> be ordinary identifiers. Same for AVX512F and zmm<N> as well as
> >> k<N>. When MMX is disabled the situation is different, due to
> >> those SSE insns which access MMX registers.
> >
> > I think we should disallow naked MMX register in SSE instructions
> > if cpummx is 0.
>
> This is not going to be acceptable in Intel syntax mode. Having to
> use % prefixes there makes no sense at all, unless explicitly
> asking for it by ".intel_syntax prefix".

I was referring to "The errors previously generated on most of these
insns in this
mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
mm<N> source operands would silently have been taken as memory operands
of those names, i.e. wrong code was silently generated."

We shouldn't allow MMX registers with ".arch .sse" if MMX isn't enabled.
You can decide what to do in "noprefix" mode.

-- 
H.J.

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[Jan Beulich]

On 13.02.2020 16:54, H.J. Lu wrote:
> On Thu, Feb 13, 2020 at 6:50 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 13.02.2020 15:15, H.J. Lu wrote:
>>> On Thu, Feb 13, 2020 at 5:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 13.02.2020 12:43, H.J. Lu wrote:
>>>>> On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> These are regular SSE/SSE2 insns, and hence should be accepted
>>>>>> irrespective of MMX as a feature being enabled. Since the MMX CPU
>>>>>> feature is intentionally not implicitly enabled by ".arch .sse", MMX
>>>>>
>>>>> This begs the question if ".arch .sse" should enable MMX.
>>>>
>>>> Well, I understood not doing so was intentional, for allowing
>>>> people to write SSE code which is free of MMX insns.
>>>
>>> True.
>>>
>>>>>> registers may be left unrecognized only when both MMX and SSE are
>>>>>> disabled. The errors previously generated on most of these insns in this
>>>>>> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
>>>>>> mm<N> source operands would silently have been taken as memory operands
>>>>>> of those names, i.e. wrong code was silently generated.
>>>>>
>>>>> This is the real problem.  What happens if YMM/ZMM are used with
>>>>> AVX disabled?
>>>>
>>>> I don't understand. When AVX is disabled, ymm<N> are expected to
>>>> be ordinary identifiers. Same for AVX512F and zmm<N> as well as
>>>> k<N>. When MMX is disabled the situation is different, due to
>>>> those SSE insns which access MMX registers.
>>>
>>> I think we should disallow naked MMX register in SSE instructions
>>> if cpummx is 0.
>>
>> This is not going to be acceptable in Intel syntax mode. Having to
>> use % prefixes there makes no sense at all, unless explicitly
>> asking for it by ".intel_syntax prefix".
> 
> I was referring to "The errors previously generated on most of these
> insns in this
> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
> mm<N> source operands would silently have been taken as memory operands
> of those names, i.e. wrong code was silently generated."
> 
> We shouldn't allow MMX registers with ".arch .sse" if MMX isn't enabled.

I disagree, and hence this patch: With ".arch .sse" _all_ SSE insns
should be legitimate to use.

Jan

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[H.J. Lu]

On Thu, Feb 13, 2020 at 8:01 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.02.2020 16:54, H.J. Lu wrote:
> > On Thu, Feb 13, 2020 at 6:50 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 13.02.2020 15:15, H.J. Lu wrote:
> >>> On Thu, Feb 13, 2020 at 5:39 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 13.02.2020 12:43, H.J. Lu wrote:
> >>>>> On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> These are regular SSE/SSE2 insns, and hence should be accepted
> >>>>>> irrespective of MMX as a feature being enabled. Since the MMX CPU
> >>>>>> feature is intentionally not implicitly enabled by ".arch .sse", MMX
> >>>>>
> >>>>> This begs the question if ".arch .sse" should enable MMX.
> >>>>
> >>>> Well, I understood not doing so was intentional, for allowing
> >>>> people to write SSE code which is free of MMX insns.
> >>>
> >>> True.
> >>>
> >>>>>> registers may be left unrecognized only when both MMX and SSE are
> >>>>>> disabled. The errors previously generated on most of these insns in this
> >>>>>> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
> >>>>>> mm<N> source operands would silently have been taken as memory operands
> >>>>>> of those names, i.e. wrong code was silently generated.
> >>>>>
> >>>>> This is the real problem.  What happens if YMM/ZMM are used with
> >>>>> AVX disabled?
> >>>>
> >>>> I don't understand. When AVX is disabled, ymm<N> are expected to
> >>>> be ordinary identifiers. Same for AVX512F and zmm<N> as well as
> >>>> k<N>. When MMX is disabled the situation is different, due to
> >>>> those SSE insns which access MMX registers.
> >>>
> >>> I think we should disallow naked MMX register in SSE instructions
> >>> if cpummx is 0.
> >>
> >> This is not going to be acceptable in Intel syntax mode. Having to
> >> use % prefixes there makes no sense at all, unless explicitly
> >> asking for it by ".intel_syntax prefix".
> >
> > I was referring to "The errors previously generated on most of these
> > insns in this
> > mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
> > mm<N> source operands would silently have been taken as memory operands
> > of those names, i.e. wrong code was silently generated."
> >
> > We shouldn't allow MMX registers with ".arch .sse" if MMX isn't enabled.
>
> I disagree, and hence this patch: With ".arch .sse" _all_ SSE insns
> should be legitimate to use.
>

Not if MMX registers are used unless MMX is enabled.

-- 
H.J.

Re: [PATCH] x86: accept SSE* insns accessing MMX registers with ".arch .nommx"

[Jan Beulich]

On 13.02.2020 17:36, H.J. Lu wrote:
> On Thu, Feb 13, 2020 at 8:01 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 13.02.2020 16:54, H.J. Lu wrote:
>>> On Thu, Feb 13, 2020 at 6:50 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 13.02.2020 15:15, H.J. Lu wrote:
>>>>> On Thu, Feb 13, 2020 at 5:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 13.02.2020 12:43, H.J. Lu wrote:
>>>>>>> On Thu, Feb 13, 2020 at 1:24 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> These are regular SSE/SSE2 insns, and hence should be accepted
>>>>>>>> irrespective of MMX as a feature being enabled. Since the MMX CPU
>>>>>>>> feature is intentionally not implicitly enabled by ".arch .sse", MMX
>>>>>>>
>>>>>>> This begs the question if ".arch .sse" should enable MMX.
>>>>>>
>>>>>> Well, I understood not doing so was intentional, for allowing
>>>>>> people to write SSE code which is free of MMX insns.
>>>>>
>>>>> True.
>>>>>
>>>>>>>> registers may be left unrecognized only when both MMX and SSE are
>>>>>>>> disabled. The errors previously generated on most of these insns in this
>>>>>>>> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
>>>>>>>> mm<N> source operands would silently have been taken as memory operands
>>>>>>>> of those names, i.e. wrong code was silently generated.
>>>>>>>
>>>>>>> This is the real problem.  What happens if YMM/ZMM are used with
>>>>>>> AVX disabled?
>>>>>>
>>>>>> I don't understand. When AVX is disabled, ymm<N> are expected to
>>>>>> be ordinary identifiers. Same for AVX512F and zmm<N> as well as
>>>>>> k<N>. When MMX is disabled the situation is different, due to
>>>>>> those SSE insns which access MMX registers.
>>>>>
>>>>> I think we should disallow naked MMX register in SSE instructions
>>>>> if cpummx is 0.
>>>>
>>>> This is not going to be acceptable in Intel syntax mode. Having to
>>>> use % prefixes there makes no sense at all, unless explicitly
>>>> asking for it by ".intel_syntax prefix".
>>>
>>> I was referring to "The errors previously generated on most of these
>>> insns in this
>>> mode perhaps wasn't actually the biggest problem - in "noprefix" mode,
>>> mm<N> source operands would silently have been taken as memory operands
>>> of those names, i.e. wrong code was silently generated."
>>>
>>> We shouldn't allow MMX registers with ".arch .sse" if MMX isn't enabled.
>>
>> I disagree, and hence this patch: With ".arch .sse" _all_ SSE insns
>> should be legitimate to use.
> 
> Not if MMX registers are used unless MMX is enabled.

Why? The directive is ".arch .sse", not ".arch .xmm". It's about
enabling of an ISA extension, not about enabling of certain
registers. Also don't forget that if this patch isn't to go in,
I'll demand that Intel syntax "cvtpi2pd xmm0, mm0" not assemble
silently to something the programmer may not have intended. As
said in the description of the change, this (and nothing else)
is my contribution to fix this issue. In the end, if you continue
to object, it'll be once again something I'll fix for Intel
syntax, recording in a comment again that AT&T mode is
intentionally left broken. I don't think it is in everyone's
interest to do so every time you disagree on a change of mine
because of personal preference.

Jan