This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: [PATCH] X86: Add pseudo prefixes to control encoding
>>> 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