This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: [PATCH] X86: Add pseudo prefixes to control encoding

On Thu, Nov 10, 2016 at 11:43 PM, Jan Beulich <> wrote:
>>>> On 10.11.16 at 22:39, <> wrote:
>> {gprmem} -- prefer gpr/mem encoding.
>> {nogprmem} -- prefer non-gpr/mem encoding.
>> They apply to both movq and pextrw.
> On one hand this is nice (as it prevents inflation of prefixes), but
> isn't this dual purpose of them also both potentially confusing and
> limiting for possible future uses?

I hope not.  Currently I restrict them to movq and pextrw.

> And then there's a slight anomaly being pointed out by your
> example:
>> [hjl@gnu-6 prefix-3]$ cat y.s
>> .text
>> movq (%rax), %xmm1
>> {nogprmem} movq (%rax), %xmm1
>> {gprmem} movq (%rax), %xmm1
>> vmovq (%rax), %xmm1
>> {nogprmem} vmovq (%rax), %xmm1
>> {gprmem} vmovq (%rax), %xmm1
> For these the assembler uses 0F 7E without prefix.
>> {evex} vmovq (%rax), %xmm1
> Here, however, it uses EVEX.0F 6E. I think the default choice would

I noticed it too.  It is due to how AVX512 support is added.
I had a patch to make it consistent with SSE/AVX.  I decided
against it since we never guarantee which encoding to use
and new pseudo prefixes provide a way to choose a specific

> better be consistent (to not surprise the programmer), just like is the
> case for vpextrw.
>> {evex} {gprmem} vmovq (%rax), %xmm1
>> {evex} {nogprmem} vmovq (%rax), %xmm1
>> pextrw $100,%xmm4,%ecx
>> {nogprmem} pextrw $100,%xmm4,%ecx
>> {gprmem} pextrw $100,%xmm4,%ecx
>> {vex2} vpextrw $100,%xmm4,%ecx
>> {vex2} {nogprmem} vpextrw $100,%xmm4,%ecx
>> {vex2} {gprmem} vpextrw $100,%xmm4,%ecx
> Shouldn't this be an error - or at least a warning -, as it can't be
> encoded with 2-byte VEX? Or else ...

Not all VEX instructions can be encoded with 2-byte VEX prefix.
I prefer {vex2} as hint and assembler does the best.

>> {vex3} vpextrw $100,%xmm4,%ecx
>> {vex3} {nogprmem} vpextrw $100,%xmm4,%ecx
>> {vex3} {gprmem} vpextrw $100,%xmm4,%ecx
>> {evex} vpextrw $100,%xmm4,%ecx
>> {evex} {nogprmem} vpextrw $100,%xmm4,%ecx
>> {evex} {gprmem} vpextrw $100,%xmm4,%ecx
>> pextrw $100,%xmm4,(%rax)
>> {gprmem} pextrw $100,%xmm4,(%rax)
> ... a {nogprmem} variant should be added (and [silently?] converted
> by the assembler) here too.
>> {vex2} vpextrw $100,%xmm4,(%rax)
>> {vex2} {nogprmem} vpextrw $100,%xmm4,(%rax)
>> {vex2} {gprmem} vpextrw $100,%xmm4,(%rax)
> These three fall into the same category.

{nogprmem} and {gprmem}  are hints. Assembler ignores them
if instructions aren't movq nor pextrw or they can't be satisfied.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]