public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: "Jiang, Haochen" <haochen.jiang@intel.com>
Cc: Hongtao Liu <crazylht@gmail.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"Liu, Hongtao" <hongtao.liu@intel.com>,
	"ubizjak@gmail.com" <ubizjak@gmail.com>
Subject: Re: [PATCH] i386: Fix aes/vaes patterns [PR114576]
Date: Mon, 8 Apr 2024 14:43:25 +0200	[thread overview]
Message-ID: <ZhPmbcRQINWlsdGF@tucnak> (raw)
In-Reply-To: <SA1PR11MB59465D152480EC22BCE4E487EC002@SA1PR11MB5946.namprd11.prod.outlook.com>

On Mon, Apr 08, 2024 at 12:33:39PM +0000, Jiang, Haochen wrote:
> Sorry for the late response since I am on vacation for now.
> 
> > As the following testcase shows, the above change was incorrect.
> > 
> > Using aes isa for the second alternative is obviously wrong, aes is enabled
> > whenever -maes is, regardless of -mavx or -mno-avx, so the above change
> > means that for -maes -mno-avx RA can choose, either it matches the first
> > alternative with the dup operand, or it matches the second one (but that
> > is of course wrong because vaesenc VEX encoded insn needs AES & AVX CPUID).
> 
> When I wrote that patch, I suppose it will never match the second one when
> AVX is not enabled because it will immediately drop to the first one so the
> second one is automatically AES && AVX, which is tricky here.

Before the -mvaes changes the alternatives were noavx,avx isa and so clearly
it was either the first alternative is the solely available, or the second,
depending on TARGET_AVX.  But with noavx,aes on the first alternative is
enabled only for !TARGET_AVX, but the second one whenever TARGET_AES, which
is both if !TARGET_AVX and TARGET_AVX.  So, the RA is free to consider both
alternatives, and because the first one is more restrictive (requires
output matching input), if there is a match between those, it will use the
first alternative, but if there isn't, it will happily use the second
alternative.

> LLVM always had less restrictions on ISA under such circumstances, I would like to
> stick to how SDM did when implementing that, which is a little conservative.
> 
> However, I am also ok with VAES implying AES if there is no real HW that has
> VAES w/o AES to reduce complexity in this scenario.

I'm fine with -mvaes not implying -maes, just want to mention that it is
fairly user visible thing and so we shouldn't be changing it after deciding
if we do it one way or another.  Now, I thought -mvaes was added in GCC 14,
but it has been around for a few years, so that means it is likely a bad
idea to change it now.

	Jakub


  reply	other threads:[~2024-04-08 12:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18  7:18 [PATCH] i386: Share AES xmm intrin with VAES Haochen Jiang
2023-04-18  7:28 ` Haochen Jiang
2023-04-19  2:31 ` Hongtao Liu
2023-04-19  2:40   ` Jiang, Haochen
2023-04-19  2:42     ` Liu, Hongtao
2024-04-04  8:41     ` [PATCH] i386: Fix aes/vaes patterns [PR114576] Jakub Jelinek
2024-04-08 12:33       ` Jiang, Haochen
2024-04-08 12:43         ` Jakub Jelinek [this message]
2024-04-08 12:46           ` Jiang, Haochen
2024-04-09  3:23       ` Hongtao Liu
2024-04-09  9:18         ` [PATCH] i386, v2: " Jakub Jelinek
2024-04-09 10:32           ` Hongtao Liu

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=ZhPmbcRQINWlsdGF@tucnak \
    --to=jakub@redhat.com \
    --cc=crazylht@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=haochen.jiang@intel.com \
    --cc=hongtao.liu@intel.com \
    --cc=ubizjak@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).