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
next prev parent 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).