[PATCH] x86: drop SSE4a from SSE check again

Jan Beulich jbeulich@suse.com
Tue Jun 9 13:53:27 GMT 2020


On 09.06.2020 15:07, H.J. Lu wrote:
> On Tue, Jun 9, 2020 at 6:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.06.2020 14:56, H.J. Lu wrote:
>>> On Tue, Jun 9, 2020 at 5:52 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 09.06.2020 14:46, Jan Beulich wrote:
>>>>> Upon re-consideration in commit 569d50f1c611 ("x86: further refine SSE
>>>>> check (SSE4a, SHA, GFNI)") I went too far: Mixing of SSE and AVX insns
>>>>> doesn't suffer as bad a penalty on AMD CPUs as on Intel ones. SSE4a
>>>>> being an AMD-only extension, it shouldn't be part of the ISA extensions
>>>>> set for which the diagnostic may get issued. Undo that part.
>>>>
>>>> I'd additionally like to note that documentation of -msse-check and
>>>> implemention are not consistent: The text says "for any SSE
>>>> instruction", yet NoAVX is also present on e.g. MOVQ2DQ and CVTPI2PS,
>>>> which clearly are SSE instructions. The question is which of the two
>>>> is wrong here.
>>>
>>> -msse-check is intended to check for SSE instructions which can be encoded with
>>> VEX.  We can update its documentation.
>>
>> IOW it is _not_ intended to help spot insns that would better be
>> replaced, and in particular ones that gas can't be told to replace
>> via -msse2avx without the programmer needing to take action?
>>
> 
> The intended usage is to verify that the assembly sources don't
> contain any VEX encodable SSE operations.

I.e. the combination of -msse2avx and -msse-check= is of no use at
all?

What about CVTPI2PD with a memory operand then? This can be re-encoded
as CVTDQ2PD and hence as VCVTDQ2PD afaict.

Jan


More information about the Binutils mailing list