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

[Jan Beulich]

>>> On 10.11.16 at 22:39, <hjl.tools@gmail.com> 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?

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
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 ...

> {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.

Jan