public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-6765] arm: suppress aes erratum when forwarding from aes Date: Thu, 20 Jan 2022 11:29:42 +0000 (GMT) [thread overview] Message-ID: <20220120112942.8D4EB3857814@sourceware.org> (raw) https://gcc.gnu.org/g:2078550a005f3fde4c331ad4b8452c963c4cdb9d commit r12-6765-g2078550a005f3fde4c331ad4b8452c963c4cdb9d Author: Richard Earnshaw <rearnsha@arm.com> Date: Mon Nov 1 13:23:26 2021 +0000 arm: suppress aes erratum when forwarding from aes AES operations are commonly chained and since the result of one AES operation is never a 32-bit value, they do not need an additional mitigation instruction for the forwarded result. We handle this common case by adding additional patterns that allow for this. gcc/ChangeLog: * config/arm/crypto.md (crypto_<CRYPTO_AESMC:crypto_pattern>_protected): New pattern. (aarch32_crypto_aese_fused_protected): Likewise. (aarch32_crypto_aesd_fused_protected): Likewise. Diff: --- gcc/config/arm/crypto.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/gcc/config/arm/crypto.md b/gcc/config/arm/crypto.md index fbee1829ce8..df857352382 100644 --- a/gcc/config/arm/crypto.md +++ b/gcc/config/arm/crypto.md @@ -75,6 +75,20 @@ [(set_attr "type" "neon_move_q")] ) +;; An AESMC operation can feed directly into a subsequent AES +;; operation without needing mitigation. +(define_insn "*crypto_<CRYPTO_AESMC:crypto_pattern>_protected" + [(set (match_operand:<crypto_mode> 0 "register_operand" "=w") + (unspec:<crypto_mode> + [(unspec:<crypto_mode> + [(match_operand:<crypto_mode> 1 "register_operand" "w")] + CRYPTO_AESMC)] + UNSPEC_AES_PROTECT))] + "TARGET_CRYPTO && fix_aes_erratum_1742098" + "<crypto_pattern>.<crypto_size_sfx>\\t%q0, %q1" + [(set_attr "type" "<crypto_type>")] +) + ;; When AESE/AESMC fusion is enabled we really want to keep the two together ;; and enforce the register dependency without scheduling or register ;; allocation messing up the order or introducing moves inbetween. @@ -95,6 +109,25 @@ (set_attr "length" "8")] ) +;; And similarly when mitigation is enabled, but not needed in this +;; case. +(define_insn "*aarch32_crypto_aese_fused_protected" + [(set (match_operand:V16QI 0 "register_operand" "=w") + (unspec:V16QI + [(unspec:V16QI + [(unspec:V16QI [(xor:V16QI + (match_operand:V16QI 1 "register_operand" "%0") + (match_operand:V16QI 2 "register_operand" "w"))] + UNSPEC_AESE)] + UNSPEC_AESMC)] + UNSPEC_AES_PROTECT))] + "TARGET_CRYPTO && fix_aes_erratum_1742098 + && arm_fusion_enabled_p (tune_params::FUSE_AES_AESMC)" + "aese.8\\t%q0, %q2\;aesmc.8\\t%q0, %q0" + [(set_attr "type" "crypto_aese") + (set_attr "length" "8")] +) + ;; When AESD/AESIMC fusion is enabled we really want to keep the two together ;; and enforce the register dependency without scheduling or register ;; allocation messing up the order or introducing moves inbetween. @@ -115,6 +148,23 @@ (set_attr "length" "8")] ) +(define_insn "*aarch32_crypto_aesd_fused_protected" + [(set (match_operand:V16QI 0 "register_operand" "=w") + (unspec:V16QI + [(unspec:V16QI + [(unspec:V16QI [(xor:V16QI + (match_operand:V16QI 1 "register_operand" "%0") + (match_operand:V16QI 2 "register_operand" "w"))] + UNSPEC_AESD)] + UNSPEC_AESIMC)] + UNSPEC_AES_PROTECT))] + "TARGET_CRYPTO && fix_aes_erratum_1742098 + && arm_fusion_enabled_p (tune_params::FUSE_AES_AESMC)" + "aesd.8\\t%q0, %q2\;aesimc.8\\t%q0, %q0" + [(set_attr "type" "crypto_aese") + (set_attr "length" "8")] +) + (define_insn "crypto_<CRYPTO_BINARY:crypto_pattern>" [(set (match_operand:<crypto_mode> 0 "register_operand" "=w") (unspec:<crypto_mode>
reply other threads:[~2022-01-20 11:29 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220120112942.8D4EB3857814@sourceware.org \ --to=rearnsha@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /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: linkBe 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).