Home Original page

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

Jan Beulich jbeulich@suse.com
Thu Feb 13 14:50:00 GMT 2020 
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
More information about the Binutils mailing list