From: Jan Beulich <jbeulich@suse.com>
To: "Cui, Lili" <lili.cui@intel.com>
Cc: "Lu, Hongjiu" <hongjiu.lu@intel.com>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [PATCH v4 3/9] Support APX GPR32 with extend evex prefix
Date: Thu, 4 Jan 2024 10:08:21 +0100 [thread overview]
Message-ID: <23d613db-1b3b-49d1-96d2-2c17a5d63a46@suse.com> (raw)
In-Reply-To: <SJ0PR11MB5600E0C7483760E9F5FB5B979E99A@SJ0PR11MB5600.namprd11.prod.outlook.com>
On 25.12.2023 13:23, Cui, Lili wrote:
>> On 19.12.2023 13:12, Cui, Lili wrote:
>>> #define Vsz256 Vsz=VSZ256
>>> #define Vsz512 Vsz=VSZ512
>>>
>>> +// The template supports VEX format for cpuid and EVEX format for cpuid &
>> apx_f.
>>> +#define APX_F(cpuid) cpuid&(cpuid|APX_F)
>>
>> I think the comment wants to go into further detail. Please can you go back to
>> read what I said when I suggested this construct, in particular regarding the
>> stripping then done? However, with you not having found a need to fiddle
>> with cpu_flags_match(), I wonder if this construct is needed in the first place.
>> The earlier suggestion was entirely based on the assumption that stripping
>> similar to that for other combined VEX/EVEX templates would be needed here,
>> t
>>
>
> Seeing this, I realized the problem and checked opcodes/i386-tbl.h, for the following entry, we want to set CpuAPX_F and CpuBMI to 1, but gen.c doesn't seem to support the format "cpuid&(cpuid|APX_F)",
I suppose you mean "cpuid|(cpuid&APX_F)"?
> in fact bzhi sets CpuBMI to 1 and CpuAPX_F to 0 . I'm not familiar with the relevant logic in gen.c and don't know how to debug it. when you have time, could you help take a look ?
Well, now that the patch was committed I of course can easily take a look.
But with such an outstanding issue, how could the patch have been committed
in the first place? And isn't it a requirement for making changes to
i386-gen.c that you sufficiently understand the logic there (which admittedly
has grown non-trivial)? Anyway - I will need to find time to play with what
has been committed, but that's not likely to happen in time for 2.42. Hence
it is quite possible that 2.42 will turn out to have incomplete and/or broken
APX_F support. But perhaps this was intended to be this way by H.J., when he
approved the entire series without even a single comment.
Jan
next prev parent reply other threads:[~2024-01-04 9:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 12:12 [PATCH v4 0/9] Support Intel APX EGPR Cui, Lili
2023-12-19 12:12 ` [PATCH v4 1/9] Support APX GPR32 with rex2 prefix Cui, Lili
2023-12-22 13:08 ` Jan Beulich
2023-12-25 6:14 ` Cui, Lili
2024-01-04 8:57 ` Jan Beulich
2023-12-19 12:12 ` [PATCH v4 2/9] Created an empty EVEX_MAP4_ sub-table for EVEX instructions Cui, Lili
2023-12-19 12:12 ` [PATCH v4 3/9] Support APX GPR32 with extend evex prefix Cui, Lili
2023-12-22 13:49 ` Jan Beulich
2023-12-25 12:23 ` Cui, Lili
2024-01-04 9:08 ` Jan Beulich [this message]
2024-01-04 12:32 ` Cui, Lili
2024-01-04 12:55 ` Jan Beulich
2023-12-22 14:19 ` Jan Beulich
2023-12-26 7:00 ` Cui, Lili
2024-01-04 9:01 ` Jan Beulich
2024-01-04 12:47 ` Cui, Lili
2023-12-19 12:12 ` [PATCH v4 4/9] Add tests for " Cui, Lili
2023-12-22 14:41 ` Jan Beulich
2023-12-25 13:40 ` Cui, Lili
2024-01-04 9:16 ` Jan Beulich
2024-01-05 6:58 ` Cui, Lili
2023-12-19 12:12 ` [PATCH v4 5/9] Support APX NDD Cui, Lili
2023-12-19 12:12 ` [PATCH v4 6/9] Support APX Push2/Pop2 Cui, Lili
2023-12-19 12:12 ` [PATCH v4 7/9] Support APX PUSHP/POPP Cui, Lili
2023-12-19 12:12 ` [PATCH v4 `8/9] Support APX NDD optimized encoding Cui, Lili
2023-12-19 12:12 ` [PATCH v4 9/9] Support APX JMPABS for disassembler Cui, Lili
2023-12-19 12:35 ` [PATCH v4 0/9] Support Intel APX EGPR Jan Beulich
2023-12-20 8:50 ` Cui, Lili
2023-12-20 8:57 ` Jan Beulich
2023-12-20 10:42 ` Cui, Lili
2023-12-20 11:00 ` Jan Beulich
2023-12-20 11:50 ` Cui, Lili
2023-12-20 12:01 ` Jan Beulich
2023-12-20 12:16 ` 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=23d613db-1b3b-49d1-96d2-2c17a5d63a46@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=hongjiu.lu@intel.com \
--cc=lili.cui@intel.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).