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-3110] arm: Fix general issues with patterns for VLLDM and VLSTM Date: Tue, 24 Aug 2021 10:58:12 +0000 (GMT) [thread overview] Message-ID: <20210824105812.09FD73858C2C@sourceware.org> (raw) https://gcc.gnu.org/g:4702d3cf044924970a9a00142542da1edacfd76c commit r12-3110-g4702d3cf044924970a9a00142542da1edacfd76c Author: Richard Earnshaw <rearnsha@arm.com> Date: Fri Jun 11 17:18:12 2021 +0100 arm: Fix general issues with patterns for VLLDM and VLSTM Both lazy_store_multiple_insn and lazy_load_multiple_insn contain invalid RTL (eg they contain a post_inc statement outside of a mem). What's more, the instructions concerned do not modify their input address register. We probably got away with this because they are generated so late in the compilation that no subsequent pass needed to understand them. Nevertheless, this could cause problems someday, so fixed to use a simple legal unspec. gcc: * config/arm/vfp.md (lazy_store_multiple_insn): Rewrite as valid RTL. (lazy_load_multiple_insn): Likewise. Diff: --- gcc/config/arm/vfp.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md index 93e963696da..9961f9389fe 100644 --- a/gcc/config/arm/vfp.md +++ b/gcc/config/arm/vfp.md @@ -1703,12 +1703,15 @@ (set_attr "type" "mov_reg")] ) +;; Both this and the next instruction are treated by GCC in the same +;; way as a blockage pattern. That's perhaps stronger than it needs +;; to be, but we do not want accesses to the VFP register bank to be +;; moved across either instruction. + (define_insn "lazy_store_multiple_insn" - [(set (match_operand:SI 0 "s_register_operand" "+&rk") - (post_dec:SI (match_dup 0))) - (unspec_volatile [(const_int 0) - (mem:SI (post_dec:SI (match_dup 0)))] - VUNSPEC_VLSTM)] + [(unspec_volatile + [(mem:BLK (match_operand:SI 0 "s_register_operand" "rk"))] + VUNSPEC_VLSTM)] "use_cmse && reload_completed" "vlstm%?\\t%0" [(set_attr "predicable" "yes") @@ -1716,11 +1719,9 @@ ) (define_insn "lazy_load_multiple_insn" - [(set (match_operand:SI 0 "s_register_operand" "+&rk") - (post_inc:SI (match_dup 0))) - (unspec_volatile:SI [(const_int 0) - (mem:SI (match_dup 0))] - VUNSPEC_VLLDM)] + [(unspec_volatile + [(mem:BLK (match_operand:SI 0 "s_register_operand" "rk"))] + VUNSPEC_VLLDM)] "use_cmse && reload_completed" "vlldm%?\\t%0" [(set_attr "predicable" "yes")
reply other threads:[~2021-08-24 10:58 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=20210824105812.09FD73858C2C@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).