From: "Cui, Lili" <lili.cui@intel.com>
To: "Beulich, Jan" <JBeulich@suse.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
"hjl.tools@gmail.com" <hjl.tools@gmail.com>
Subject: RE: [PATCH] Support {evex} pseudo prefix for decode evex promoted insns without egpr32.
Date: Wed, 20 Mar 2024 13:12:36 +0000 [thread overview]
Message-ID: <SJ0PR11MB56009AFB64BDE7A058F009C69E332@SJ0PR11MB5600.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1b29c006-7ea6-40d4-ac7c-1c0b40c6243c@suse.com>
> On 06.03.2024 10:58, Cui, Lili wrote:
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/noreg64-evex.s
>
> This separate test, not directly fitting with the patch title, wants mentioning in
> the patch description.
>
Ok.
> > @@ -0,0 +1,67 @@
> > +# Check 64-bit insns not sizeable through register operands with evex
> > + .text
> > + {evex} adc $1, (%rax)
> > + {evex} adc $0x89, (%rax)
> > + {evex} adc $0x1234, (%rax)
> > + {evex} adc $0x12345678, (%rax)
> > + {evex} add $1, (%rax)
> > + {evex} add $0x89, (%rax)
> > + {evex} add $0x1234, (%rax)
> > + {evex} add $0x12345678, (%rax)
> > + {evex} and $1, (%rax)
> > + {evex} and $0x89, (%rax)
> > + {evex} and $0x1234, (%rax)
> > + {evex} and $0x12345678, (%rax)
> > + {evex} crc32 (%rax), %eax
>
> noreg64.s tests %rax as a destination separately, for a reason.
I don't know the reason why noreg64.s uses %rax, so it just follows the previous style. Do you know why? Is it not necessary to keep using %rax in the current test file?
> > + {evex} sbb $1, (%rax)
> > + {evex} sbb $0x89, (%rax)
> > + {evex} sbb $0x1234, (%rax)
> > + {evex} sbb $0x12345678, (%rax)
> > + {evex} sar $1, (%rax)
>
> Like noreg64.s please have "sal" tests here, too.
>
Added.
> > --- a/gas/testsuite/gas/i386/x86-64-apx-ndd-optimize.d
> > +++ b/gas/testsuite/gas/i386/x86-64-apx-ndd-optimize.d
> > @@ -118,7 +118,7 @@ Disassembly of section .text:
> > \s*[a-f0-9]+:\s*67 0f 4d 90 90 90 90 90 cmovge -
> 0x6f6f6f70\(%eax\),%edx
> > \s*[a-f0-9]+:\s*67 0f 4e 90 90 90 90 90 cmovle -
> 0x6f6f6f70\(%eax\),%edx
> > \s*[a-f0-9]+:\s*67 0f 4f 90 90 90 90 90 cmovg -
> 0x6f6f6f70\(%eax\),%edx
> > -\s*[a-f0-9]+:\s*62 f4 7d 08 60 c0 movbe %ax,%ax
> > +\s*[a-f0-9]+:\s*62 f4 7d 08 60 c0 \{evex\} movbe %ax,%ax
>
> This is wrong: An {evex} prefix should appear on MOVBE only when there's a
> memory operand (and no use of an eGPR).
OK, I will fix it.
>
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-apx_f-evex-intel.d
> > @@ -0,0 +1,1197 @@
> > +#as:
> > +#objdump: -dw -Mintel
> > +#name: x86_64 APX_F insns with evex pseudo prefix (Intel disassembly)
>
> Is an Intel disassembly variant of this test really worth it? It's not exactly small,
> after all. If you want to keep it, ...
>
I prefer to drop it.
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-apx_f-evex.d
> > @@ -0,0 +1,1197 @@
> > +#as:
> > +#objdump: -dw
> > +#name: x86_64 APX_F insns with evex pseudo prefix
> > +#source: x86-64-apx_f-evex.s
> > +
> > +.*: +file format .*
> > +
> > +Disassembly of section \.text:
> > +
> > +0+ <_start>:
> > +\s*[a-f0-9]+:\s*62 54 fc 08 fc bc 80 23 01 00 00\s+\{evex\}
> > +aadd\s+%r15,0x123\(%r8,%rax,4\)
>
> ... please bring its expectations in line with this (just a single blank between
> {evex} and the insn menmonic).
>
Changed x86-64-apx_f-evex.s to use space instead of tab between {evex} and mnemonic.
> > --- /dev/null
> > +++ b/gas/testsuite/gas/i386/x86-64-apx_f-evex.s
> > @@ -0,0 +1,1192 @@
> > +# Check 64bit APX_F instructions with evex pseudo prefix
> > +
> > + {evex} imul %r15
> > + {evex} imul %r15,%r15
> > + {evex} imul %r15d
> > + {evex} imul %r15d,%edx
> > + {evex} imul %r15w
> > + {evex} imul %r15w,%ax
> > + {evex} imul %r8b
> > + {evex} imulb 0x123(%r8,%rax,4)
> > + {evex} imulw 0x123(%r8,%rax,4)
> > + {evex} imull 0x123(%r8,%rax,4)
> > + {evex} imul 0x123(%r8,%rax,4),%r15
> > + {evex} imul 0x123(%r8,%rax,4),%r15d
> > + {evex} imul 0x123(%r8,%rax,4),%r15w
> > + {evex} imulq 0x123(%r8,%rax,4)
> > + {evex} imul $0x7b, %dx, %ax
> > + {evex} imul $0x7b, %ecx, %edx
> > + {evex} imul $0x7b, %r9, %r15
> > + {evex} imul $0x7b, 291(%r8, %rax, 4), %dx
> > + {evex} imul $0x7b, 291(%r8, %rax, 4), %ecx
> > + {evex} imul $0x7b, 291(%r8, %rax, 4), %r9
> > + {evex} imul $0xff90, %dx, %ax
> > + {evex} imul $0xff90, %ecx, %edx
> > + {evex} imul $0xff90, %r9, %r15
> > + {evex} imul $0xff90, 291(%r8, %rax, 4), %dx
> > + {evex} imul $0xff90, 291(%r8, %rax, 4), %ecx
> > + {evex} imul $0xff90, 291(%r8, %rax, 4), %r9
>
> Also covering the 2-operand forms of these (srcreg == dstreg) would seem
> desirable.
I'm a little confused here, do you suggest adding such a testcase?
{evex} imul $0x7b, %r9, %r9
>
> > + {evex} movbe %r15,%r15
>
> No {evex} needed here, ...
>
> > + {evex} movbe %r15,0x123(%r8,%rax,4)
> > + {evex} movbe %r15d,%edx
>
> ... here, or ...
>
> > + {evex} movbe %r15d,0x123(%r8,%rax,4)
> > + {evex} movbe %r15w,%ax
>
> ... here (iow these three can be omitted).
Ok, I'll remove them from this test file and add them to x86-64-apx-evex-promoted.s.
> > + {evex} ror $0x7b,%r15
> > + {evex} ror $0x7b,%r15d
> > + {evex} ror $0x7b,%r15w
> > + {evex} ror $0x7b,%r8b
> > + {evex} rorb $0x7b,0x123(%r8,%rax,4)
> > + {evex} rorw $0x7b,0x123(%r8,%rax,4)
> > + {evex} rorl $0x7b,0x123(%r8,%rax,4)
> > + {evex} rorq $0x7b,0x123(%r8,%rax,4)
> > + {evex} ror $1,%r15
> > + {evex} ror $1,%r15d
> > + {evex} ror $1,%r15w
> > + {evex} ror $1,%r8b
> > + {evex} rorb $1,0x123(%r8,%rax,4)
> > + {evex} rorw $1,0x123(%r8,%rax,4)
> > + {evex} rorl $1,0x123(%r8,%rax,4)
> > + {evex} rorq $1,0x123(%r8,%rax,4)
> > + {evex} ror %cl,%r15
> > + {evex} ror %cl,%r15d
> > + {evex} ror %cl,%r15w
> > + {evex} ror %cl,%r8b
> > + {evex} rorb %cl,0x123(%r8,%rax,4)
> > + {evex} rorw %cl,0x123(%r8,%rax,4)
> > + {evex} rorl %cl,0x123(%r8,%rax,4)
> > + {evex} rorq %cl,0x123(%r8,%rax,4)
> > + {evex} rorx $0x7b,%r15,%r15
> > + {evex} rorx $0x7b,%r15d,%edx
> > + {evex} rorx $0x7b,0x123(%r8,%rax,4),%r15
> > + {evex} rorx $0x7b,0x123(%r8,%rax,4),%r15d
> > + {evex} sar $0x7b,%r15
>
> Please also again cover "sal".
>
Ok.
> > + {evex} xor $0x7b,%r15
> > + {evex} xor $0x7b,%r15d
> > + {evex} xor $0x7b,%r15w
> > + {evex} xor $0x7b,%r8b
> > + {evex} xorb $0x7b,0x123(%r8,%rax,4)
> > + {evex} xorw $0x7b,0x123(%r8,%rax,4)
> > + {evex} xorl $0x7b,0x123(%r8,%rax,4)
> > + {evex} xorq $0x7b,0x123(%r8,%rax,4)
> > + {evex} xor %r15,%r15
> > + {evex} xor %r15,0x123(%r8,%rax,4)
> > + {evex} xor %r15d,%edx
> > + {evex} xor %r15d,0x123(%r8,%rax,4)
> > + {evex} xor %r15w,%ax
> > + {evex} xor %r15w,0x123(%r8,%rax,4)
> > + {evex} xor %r8b,%dl
> > + {evex} xor %r8b,0x123(%r8,%rax,4)
> > + {evex} xor 0x123(%r8,%rax,4),%r15
> > + {evex} xor 0x123(%r8,%rax,4),%r15d
> > + {evex} xor 0x123(%r8,%rax,4),%r15w
> > + {evex} xor 0x123(%r8,%rax,4),%r8b
> > +
> > + .intel_syntax noprefix
>
> Along the lines of the earlier remark, I wonder whether this repetition of
> everything is really useful to have.
Dropped.
Thanks,
Lili.
next prev parent reply other threads:[~2024-03-20 13:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 9:58 Cui, Lili
2024-03-08 10:37 ` Jan Beulich
2024-03-20 13:12 ` Cui, Lili [this message]
2024-03-20 13:21 ` Jan Beulich
2024-03-21 12:33 ` Cui, Lili
2024-03-22 9:45 ` Cui, Lili
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR11MB56009AFB64BDE7A058F009C69E332@SJ0PR11MB5600.namprd11.prod.outlook.com \
--to=lili.cui@intel.com \
--cc=JBeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).