public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Cui, Lili" <lili.cui@intel.com>
Cc: Binutils <binutils@sourceware.org>,
	"H.J. Lu" <hjl.tools@gmail.com>, Hongtao Liu <crazylht@gmail.com>
Subject: Re: [PATCH 0/4] x86: fold a number of VEX and EVEX templates
Date: Mon, 18 Sep 2023 13:49:39 +0200	[thread overview]
Message-ID: <7c2f758e-233d-52e9-d836-2133491adb13@suse.com> (raw)
In-Reply-To: <SJ0PR11MB5600CA415D0B5D85F52FC9119EFBA@SJ0PR11MB5600.namprd11.prod.outlook.com>

On 18.09.2023 13:18, Cui, Lili wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, September 18, 2023 5:38 PM
>> To: Cui, Lili <lili.cui@intel.com>
>> Cc: Binutils <binutils@sourceware.org>; H.J. Lu <hjl.tools@gmail.com>;
>> Hongtao Liu <crazylht@gmail.com>
>> Subject: Re: [PATCH 0/4] x86: fold a number of VEX and EVEX templates
>>
>> On 18.09.2023 07:47, Cui, Lili wrote:
>>>> -----Original Message-----
>>>> From: Hongtao Liu <crazylht@gmail.com>
>>>> Sent: Monday, September 18, 2023 9:58 AM
>>>>
>>>> On Fri, Sep 15, 2023 at 4:46 PM Jan Beulich via Binutils
>>>> <binutils@sourceware.org> wrote:
>>>>>
>>>>> The last two patches are explicitly RFC, for having a possibly
>>>>> unwanted side effect.
>>>> We're about to send out APX patches, @Lili Cui  cloud you take a look
>>>> at the series?
>>>
>>> Since APX only needs to promote the VEX instructions without
>> corresponding EVEX, these folding VEX and EVEX template patches has no
>> effect on our internal APX patches.
>>
>> I don't follow: As soon as you have an insn with both a VEX and an EVEX
>> encoding, there can be potential for folding (ideally right when APX is being
>> introduced, rather than once again leaving it to me to clean up later).
> 
> Oh, I got your point. After your patches checked in,  I will fold VEX and EVEX  after we have promoted-EVEX. 

Just fyi that I'll likely need a v2 of those patches. While thinking of how
to remove the odd behavior of the latter two patches, I also spotted an
anomaly (even if largely benign right now) in the first one. I'll have to
think about that some more (just to be reasonably sure not to introduce yet
new quirks), so I won't post right away.

Jan

  reply	other threads:[~2023-09-18 11:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15  8:46 Jan Beulich
2023-09-15  8:47 ` [PATCH 1/4] x86: fold certain " Jan Beulich
2023-09-15  8:48 ` [PATCH 2/4] x86: fold VAES/VPCLMULQDQ " Jan Beulich
2023-09-15  8:48 ` [PATCH RFC 3/4] x86: fold FMA " Jan Beulich
2023-09-15  8:49 ` [PATCH RFC 4/4] x86: fold F16C " Jan Beulich
2023-09-18  1:58 ` [PATCH 0/4] x86: fold a number of " Hongtao Liu
2023-09-18  5:47   ` Cui, Lili
2023-09-18  9:38     ` Jan Beulich
2023-09-18 11:18       ` Cui, Lili
2023-09-18 11:49         ` Jan Beulich [this message]
2023-09-18 12:03           ` 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=7c2f758e-233d-52e9-d836-2133491adb13@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=crazylht@gmail.com \
    --cc=hjl.tools@gmail.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).