From: Jan Beulich <jbeulich@suse.com>
To: "Jiang, Haochen" <haochen.jiang@intel.com>
Cc: "hjl.tools@gmail.com" <hjl.tools@gmail.com>,
"binutils@sourceware.org" <binutils@sourceware.org>
Subject: Re: [PATCH 04/10] Support Intel CMPccXADD
Date: Thu, 27 Oct 2022 08:37:41 +0200 [thread overview]
Message-ID: <c16e544f-873f-8225-f9f5-83c9c9fa3af8@suse.com> (raw)
In-Reply-To: <SA1PR11MB59467DE4C895750514A65953EC339@SA1PR11MB5946.namprd11.prod.outlook.com>
On 27.10.2022 05:09, Jiang, Haochen wrote:
>
>
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, October 26, 2022 4:50 PM
>> To: Jiang, Haochen <haochen.jiang@intel.com>
>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>> Subject: Re: [PATCH 04/10] Support Intel CMPccXADD
>>
>> On 26.10.2022 05:03, Jiang, Haochen wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Tuesday, October 25, 2022 2:53 PM
>>>> To: Jiang, Haochen <haochen.jiang@intel.com>
>>>> Cc: hjl.tools@gmail.com; binutils@sourceware.org
>>>> Subject: Re: [PATCH 04/10] Support Intel CMPccXADD
>>>>
>>>> On 24.10.2022 07:55, Jiang, Haochen wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Friday, October 14, 2022 9:47 PM
>>>>>>
>>>>>> On 14.10.2022 11:12, Haochen Jiang wrote:
>>>>>> And finally - is SwapSources really appropriate to use here?
>>>>>> There's only
>>>> one
>>>>>> pure source operand, the other two are also serving as destinations.
>>>>>> I wonder whether an attribute is necessary here in the first place:
>>>>>> Vex-
>>>> encoded
>>>>>> insns with a memory destination never have two further register
>>>> operands, so
>>>>>> that property should suffice for identifying the case in
>>>> build_modrm_byte().
>>>>>> Alternatively you could also simply use the CPU flag.
>>>>>
>>>>> We may need a special identifier for CMPccXADD since we have VVVV at
>>>>> operand 3, where it is always at operand 2 for all other insts which
>>>>> have VVVV. That is the reason we reuse SwapSources. It might be not
>>>>> that same as the original meaning. But we want to avoid adding a bit
>>>>> for this very rare case. Do we need to change that?
>>>>
>>>> Re-using existing attributes is certainly preferred. But the question
>>>> here was whether _any_ special attribute is needed. Did you try out
>>>> my suggestion, and it didn't work out for some reason? Avoiding the
>>>> (ab)use of an inappropriately (for the purpose here) named attribute
>>>> would imo be preferable.
>>>
>>> Actually we have some similar instructions. For example, vmaskmovps/d.
>>> It could also take one memory operand as dest and two register
>>> operands as source.
>>
>> As you say there are two _source_ operands here, whereas ...
>>
>>> However, cmp<cc>xadd has a different encoding pattern with it. The
>>> default behavior for previous insts like vmaskmovps/d in Intel syntax
>>> is to encode first register operand as vvvv and second register operand as
>> modrm:reg.
>>> In cmp<cc>xadd, it is swapped, with first register operand as
>>> modrm:reg and second register operand as vvvv. I suppose it makes
>>> sense to use SwapSource and it is quite hard or might be dirty to just
>>> use the number of registers to identify them in build_modrm_byte().
>>
>> ... this has two destinations (memory and a register). Which is why using
>> SwapSource at best is a slight abuse (which, as said, I'd prefer to avoid).
>> But yes, I agree that going _just_ from a memory destination with two
>> further register ops is not sufficient.
>>
>> Seeing what H.J. and I are suggesting for the PREFETCHI change: How about
>> using the CPU flag in the conditional that you add?
>
> That is ok for me. I suppose the cmpccxadd might be the special one for very
> long time.
>
> However, the potential problem is when the same scenario happen again. We
> will have to add another cpuid at that condition again, which is a little dirty.
I guess we can decide at that point whether a 2nd CPU check is preferable
over whatever alternative.
Jan
next prev parent reply other threads:[~2022-10-27 6:37 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 9:12 [PATCH 0/10] Add new Intel Sierra Forest, Grand Ridge, Granite Rapids Instructions Haochen Jiang
2022-10-14 9:12 ` [PATCH 01/10] Support Intel AVX-IFMA Haochen Jiang
2022-10-14 9:52 ` Jan Beulich
2022-10-14 18:10 ` H.J. Lu
2022-10-16 6:39 ` Jan Beulich
2022-10-17 22:23 ` H.J. Lu
2022-10-18 5:33 ` Jan Beulich
2022-10-18 21:28 ` H.J. Lu
2022-10-19 6:01 ` Jan Beulich
2022-10-19 21:27 ` H.J. Lu
2022-10-20 6:15 ` Jan Beulich
2022-10-24 2:07 ` Jiang, Haochen
2022-10-24 5:53 ` Jiang, Haochen
2022-10-24 19:09 ` H.J. Lu
2022-10-25 6:29 ` Jan Beulich
2022-10-14 9:12 ` [PATCH 02/10] Support Intel AVX-VNNI-INT8 Haochen Jiang
2022-10-14 10:57 ` Jan Beulich
2022-10-21 3:22 ` Jiang, Haochen
2022-10-25 1:52 ` H.J. Lu
2022-10-14 9:12 ` [PATCH 03/10] Support Intel AVX-NE-CONVERT Haochen Jiang
2022-10-14 12:58 ` Jan Beulich
2022-10-24 5:37 ` Kong, Lingling
2022-10-24 5:59 ` Kong, Lingling
2022-10-24 19:25 ` H.J. Lu
2022-10-25 6:44 ` Jan Beulich
2022-10-14 9:12 ` [PATCH 04/10] Support Intel CMPccXADD Haochen Jiang
2022-10-14 13:46 ` Jan Beulich
2022-10-14 18:27 ` H.J. Lu
2022-10-14 21:51 ` H.J. Lu
2022-10-16 6:34 ` Jan Beulich
2022-10-17 23:31 ` H.J. Lu
2022-10-16 6:25 ` Jan Beulich
2022-10-17 23:44 ` H.J. Lu
2022-10-16 6:19 ` Jan Beulich
2022-10-24 2:30 ` Jiang, Haochen
2022-10-24 19:12 ` H.J. Lu
2022-10-24 5:55 ` Jiang, Haochen
2022-10-25 6:53 ` Jan Beulich
2022-10-26 3:03 ` Jiang, Haochen
2022-10-26 8:49 ` Jan Beulich
2022-10-27 3:09 ` Jiang, Haochen
2022-10-27 6:37 ` Jan Beulich [this message]
2022-10-28 0:59 ` Jiang, Haochen
2022-10-14 9:12 ` [PATCH 05/10] Add handler for more i386_cpu_flags Haochen Jiang
2022-10-14 13:53 ` Jan Beulich
2022-10-14 9:12 ` [PATCH 06/10] Support Intel RAO-INT Haochen Jiang
2022-10-14 14:38 ` Jan Beulich
2022-10-16 6:15 ` Jan Beulich
2022-10-24 3:12 ` Jiang, Haochen
2022-10-24 19:17 ` H.J. Lu
2022-10-24 5:56 ` Jiang, Haochen
2022-10-25 7:01 ` Jan Beulich
2022-10-26 5:16 ` Jiang, Haochen
2022-10-26 8:56 ` Jan Beulich
2022-10-27 3:50 ` Jiang, Haochen
2022-10-27 6:39 ` Jan Beulich
2022-10-27 18:46 ` H.J. Lu
2022-10-28 6:52 ` Jan Beulich
2022-10-28 8:10 ` Jiang, Haochen
2022-10-28 8:22 ` Jan Beulich
2022-10-28 8:31 ` Jiang, Haochen
2022-10-28 8:40 ` Jan Beulich
2022-10-28 16:08 ` H.J. Lu
2022-10-31 9:41 ` Jan Beulich
2022-10-31 16:49 ` H.J. Lu
2022-11-06 12:50 ` Kong, Lingling
2022-11-07 9:24 ` Jan Beulich
2022-11-07 13:37 ` Kong, Lingling
2022-11-07 20:03 ` H.J. Lu
2022-10-17 23:23 ` H.J. Lu
2022-10-18 5:38 ` Jan Beulich
2022-10-14 9:12 ` [PATCH 07/10] Support Intel WRMSRNS Haochen Jiang
2022-10-17 7:17 ` Jan Beulich
2022-10-24 2:52 ` Jiang, Haochen
2022-10-24 5:56 ` Jiang, Haochen
2022-10-24 19:14 ` H.J. Lu
2022-10-25 7:04 ` Jan Beulich
2022-10-14 9:12 ` [PATCH 08/10] Support Intel MSRLIST Haochen Jiang
2022-10-17 7:20 ` Jan Beulich
2022-10-24 3:03 ` Jiang, Haochen
2022-10-24 5:56 ` Jiang, Haochen
2022-10-24 19:15 ` H.J. Lu
2022-10-25 7:07 ` Jan Beulich
2022-10-14 9:12 ` [PATCH 09/10] Support Intel AMX-FP16 Haochen Jiang
2022-10-17 7:35 ` Jan Beulich
2022-10-18 9:01 ` Cui, Lili
2022-10-18 9:23 ` Jan Beulich
2022-10-18 9:33 ` Jiang, Haochen
2022-10-19 10:33 ` Cui, Lili
2022-10-19 13:35 ` Jan Beulich
2022-10-19 14:05 ` Cui, Lili
2022-10-19 14:09 ` Jan Beulich
2022-10-19 14:41 ` Cui, Lili
2022-10-19 15:04 ` Jan Beulich
2022-10-19 15:21 ` Cui, Lili
2022-10-19 14:01 ` Jiang, Haochen
2022-10-19 14:13 ` Jan Beulich
2022-10-19 14:58 ` Jiang, Haochen
2022-10-25 6:02 ` Jan Beulich
2022-10-25 13:05 ` Cui, Lili
2022-10-14 9:12 ` [PATCH 10/10] Support Intel PREFETCHI Haochen Jiang
2022-10-17 8:15 ` Jan Beulich
2022-10-25 13:03 ` Cui, Lili
2022-10-25 15:41 ` Jan Beulich
2022-10-25 15:52 ` Jan Beulich
2022-10-25 17:01 ` H.J. Lu
2022-10-26 13:42 ` Cui, Lili
2022-10-26 13:53 ` Jan Beulich
2022-10-27 6:04 ` Cui, Lili
2022-10-27 6:45 ` Jan Beulich
2022-10-27 7:01 ` Cui, Lili
2022-10-27 7:15 ` Jan Beulich
2022-10-27 7:43 ` Cui, Lili
2022-10-28 9:03 ` Cui, Lili
2022-10-28 15:54 ` H.J. Lu
2022-10-31 13:23 ` Cui, Lili
2022-10-31 14:45 ` Mike Frysinger
2022-10-31 16:25 ` H.J. Lu
2022-10-19 14:55 [PATCH v2 0/10] Add new Intel Sierra Forest, Grand Ridge, Granite Rapids Instructions Haochen Jiang
2022-10-19 14:56 ` [PATCH 04/10] Support Intel CMPccXADD Haochen Jiang
2022-10-19 15:15 [PATCH v2 0/10] Add new Intel Sierra Forest, Grand Ridge, Granite Rapids Instructions (Resend) Haochen Jiang
2022-10-19 15:15 ` [PATCH 04/10] Support Intel CMPccXADD Haochen Jiang
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=c16e544f-873f-8225-f9f5-83c9c9fa3af8@suse.com \
--to=jbeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=haochen.jiang@intel.com \
--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).