This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: optimal encoding of SIMD insns
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "Binutils" <binutils at sourceware dot org>
- Date: Mon, 20 Nov 2017 06:09:44 -0700
- Subject: Re: optimal encoding of SIMD insns
- Authentication-results: sourceware.org; auth=none
- References: <5A12D3C0020000780019004E@prv-mh.provo.novell.com> <CAMe9rOqJ9G_3qWZqdu2CARy00wbETcb16J3NbxtDJhiZ=EKZcQ@mail.gmail.com>
>>> On 20.11.17 at 13:55, <hjl.tools@gmail.com> wrote:
> On Mon, Nov 20, 2017 at 4:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> H.J.,
>>
>> one more sub-optimal thing I've come across, int the context of my
>> analysis of whether Vec_Disp8 really is fully redundant with
>> DispMemShift: Certain instructions, for example
>>
>> vaddps xmm0, xmm0, [eax+0x80]
>>
>> are encodable with both VEX and EVEX. Generally the assembler
>> tries to pick the shortest encoding. Obviously the VEX encoding,
>> due to requiring the Disp32 ModR/M form, is longer than the
>> EVEX one in the specific example above. Clearly such a
>> conversion can't be done unilaterally, as that could break code
>> assuming to be run on AVX-512-incapable hardware. However,
>> does anything speak against doing so after having seen a
>> command line option or directive explicitly enabling AVX-512
>> insns? Or should this instead be made even more explicit, by
>> introducing something paralleling the automatic SSE->AVX
>> conversion?
>>
>
> Have you looked at
>
> commit 86fa6981e7487e2c2df4337aa75ed2d93c32eaf2
> Author: H.J. Lu <hjl.tools@gmail.com>
> Date: Thu Mar 9 09:58:46 2017 -0800
>
> X86: Add pseudo prefixes to control encoding
>
> Many x86 instructions have more than one encodings. Assembler picks
> the default one, usually the shortest one. Although the ".s", ".d8"
> and ".d32" suffixes can be used to swap register operands or specify
> displacement size, they aren't very flexible. This patch adds pseudo
> prefixes, {xxx}, to control instruction encoding. The available
> pseudo prefixes are {disp8}, {disp32}, {load}, {store}, {vex2}, {vex3}
> and {evex}. Pseudo prefixes are preferred over the ".s", ".d8" and
> ".d32" suffixes, which are deprecated.
Yes, but that requires explicit action on part of the programmer or
compiler on every individual affected insn. Especially for the latter I
doubt it will (or even should) emit such pseudo prefixes.
Jan